Regarding HWID, we can decode HWID string to HW component info only if HWID database is accessible so we might need to put all HWID database into a single uni-build image. On the other hand, we intend to hide HWID databases among partners therefore how could we put all databases into a single uni-build image?

Alternative way is to translate database from relatively detail of components into a simple list of HW presence then install into OS. In this way, we don't leak detail but just get whether certain HW is presented or not.

Regarding master config, it might be straightforward to add more information about HW presence for each SKU IDs.

> Alternative way is to translate database from relatively detail of components into a simple list of HW presence then install into OS.

I found this is not enough if we only rely on it. The reason is that the translated database for HW presence doesn't have info to show which SKU IDs have the component A and others not because HWID database itself is just a super set.

What attributes are you looking for to expose? 

touchscreen?
trackpad?
digitizer?

Anything else you were thinking?

re #4: once the hwid is set at manufacturing we can retrieve that info w.r.t. expectations. That said, I'm not sure if you wanting to utilize this information at manufacturing or only post-manufacturing.

re #1: what is in the hwid that makes sharing it bad? I'm curious as many attributes are already available from the nature of open source development.

re#5,

> re #4: once the hwid is set at manufacturing we can retrieve
I confused myself actually. HWID should be reliable after factory finalize then we do really can extract info like 'touchscreen: componentX or None' by decoding it with HWID database (or translated one if we want to hide component details.)

And yes, as you implied in your question this should be only available in post-manufacturing. During the factory build, we need other source (model_sku.json currently) to verify component combination first then generated HWID would just be correct.

> What attributes are you looking for to expose? 
Regarding report to ARC++, it would be
  sensors including gyro, accelerometer, light and others. (not in HWID)
  rear camera
  touchscreen

Regarding factory (a specific component should be assembled or not), 
  sensors
  rear camera
  touchscreen

  stylus, convertible or clamshell, hw button, power led 

> re #1: what is in the hwid that makes sharing it bad?
hmm~~~ no accurate answer yet.

Until now, there are some points to show HWID is not a proper solution here and they are

  1. Some factors/components are not in HWID scope now. For example, they are sensors, form factor (ex: convertible, clamshell ...etc), HW button and power LED.

  2. One use case is for factory process to ensure what components should be presented so when a component can't be probed we know it is because this SKU doesn't have it (intended) or actually it is broken / not assembled accidentally. This can't be covered by HWID too since it is a super set of components.

  3. HWID is currently in the AP flash (GBB section in AP FW) so EC can't leverage it for info like 'is_convertible' currently.

Taking all these points, it looks like it's time to evaluate another approach - master config. And actually it is under discussion in b/111802594 now including how to publish master config into EC.

Currently there are three proposals related to this topic:
  1. b/111802594: Put HW presence in master config and distribute to EC or coreboot by generating codes for FW to import.
  2. b/117217160 comment 17: improve the scheme in nami.
  3. design doc - Chrome OS Device Identifier Guideline.

Since they covered this topic here, I close this issue first.