Going forward, this sounds fine.

I don't think we're going to change the exiting behavior though.

Instead, this should be 'add oem-id' going forward in lieu of smbios-name-match

"should oem_id in EEPROM makes more sense to be in the identity?"

Are you just suggesting oem_id be in that table you linked? 

"Instead, this should be 'add oem-id' going forward in lieu of smbios-name-match" 

That field is not globally unique. It's inherently namespaced within a 'project', such as octopus. And it can't be globally unique because it's exposing who the oem is.

Could I get clarification on the original filing and #3 ?

> Are you just suggesting oem_id be in that table you linked? 

Yes, to replace smbios-name-match.

> And it can't be globally unique

It is ok for the purpose here since the matching identity is project based originally. For example, octopus has it's own model.yaml to list mapping between identity and models.

On the other hand, SKU ID can be unique per ODM or globally in a project scope (like octopus is per ODM but coral is globally in a project scope) so the identity of SKU ID + OEM ID is enough to make it unique in every project scope (ex: octopus and coral).

smbios-name-match is similar to OEM ID but smbios-name-match would be affected by firmware updating theoretically but OEM ID should be always the same in a DUT. 

re #5: so oem-id in this case is a string. got it. However, I'm not sure how weird that will look in the face of coral and nami/fizz that are sharing firmware. The string won't be unique across those models. It'll be the same since that string is essentially targeting a namespace of values to further refine the model lookup.

"For example, octopus has it's own model.yaml to list mapping between identity and models."

That's not exactly true w.r.t. mosys currently. More than one platform is included in the builds for proving purposes. It's kinda silly, but that's how it is. To add to the silliness we are still encoding strings to match in the code for the probing even when cros_config info is available. Anyway, I just wanted to point out that having a list of accepted platforms doesn't mean we can't get false matches.

"smbios-name-match is similar to OEM ID but smbios-name-match would be affected by firmware updating theoretically but OEM ID should be always the same in a DUT."

This I'm not following. What values and types do you think OEM ID is taking on? This sounds like something that is *in addition* to smbios-name-match. Otherwise you can't steer the code to do a selection within the proper namespace.

re#6,

From my point of view, models shared the same or had different FW should not impact how identity looks like. And the namespace of SKU ID, which is per OEM or not, should not impact too.  For example, there are OEM ID - [1|2] and each of them have two models (each models has one SKU ID only) then the identify can be (oem_id, sku_id):

  case 1: (1, 0), (1, 1), (2, 2), (2, 3) : if SKU ID is not per OEM.

  case 2: (1, 0), (1, 1), (2, 0), (2, 1) : if SKU ID is per OEM.

And no matter case 1 or 2, the firmware name can be defined for each of them and that firmware name can be all the same (shared firmware) or not (per OEM). So I don't see what weird we might see in Coral or Nami.

> list of accepted platforms doesn't mean we can't get false matches.

Yes, there are a list of platforms in mosys [1] but there is 'only one' master config (model.yaml) in the OS image. By the way, platform mis-match in mosys is another topic?

> What values and types do you think OEM ID is taking on?

OEM ID now is already in the EEPROM and defined in go/octopus-cbi-settings.

[1] and for octopus it tries to probe product name from SMBIOS for matching although I think Family from SMBIOS should be the one.

 

My quibble is with the term oem-id proper. It doesn't exactly match for nami and coral. On the coral front the value would be 'reef' which as you noted is not unique to the OEM so it doesn't really provide distinction of the OEM at all. Similarly, the OEM ID in cbi on octopus would never be reflected in the yaml oem-id field because that's not the information required to make the correct decisions in identity matching. It'd be the name of the firmware build target to namespace the decision path properly. The proposal for this bug is replacing a field's name that doesn't exactly provide the information that the name suggests. i.e. smbios-name-match -> oem-id. Or am I misunderstanding this bug?

Yes, mosys is another topic, but these topics are closely related because mosys is utilizing these things through cros_config to make identity decisions. Yes, there's only one master config, but the current code is evaluating multiple platforms using master config, smbios name, plus a hard coded string in mosys to make the decision on the x86 devices. It works by ensuring all those 3 things match up.

I'm thinking we add oem-id as an additional field while still having smbios-name-match. That makes the most sense to me given we have vastly different interpretations of the values and types for these fields in practice.

Let me know if I'm misunderstanding anything.

Thanks for Aaron's patient first.

> i.e. smbios-name-match -> oem-id. Or am I misunderstanding this bug?

Yes, I am not requesting to just change name of smbios-name-match to oem-id and not about the source of value is still came from product_name of SMBIOS. What I suggest is for cros_config to read 'OEM_ID' from EEPROM (via any interfaces) as oem_id in identity. As a result, in case of nami and octopus the identify will be all came from values in EEPROM. Regarding coral which didn't introduce oem_id, it can be a legacy support to identity of smbios-name-match and SKU ID.

> evaluating multiple platforms using master config

I would suggest 'family' + 'hard coded string in mosys' for selecting correct master config. And 'oem_id' + 'sku_id' for identifying models. Then model points out build target name of fw, Key / Signature ID and others. In this case, we don't need smbios-name-match?

The issue is that mosys is not currently build targeting a specific os-image/overlay. It has nearly all the devices' probing methods in it. This is why my comments about current mosys implementation matter. One *cannot* start off just reading oem_id from CBI and getting a value. The reason is that the value is not namespaced. There's no way of knowing what that value represents. The first step is steering the code into utilizing the correct set of data to make further decisions. On x86 that's currently using smbios.

In the 2nd part of your response in #9 you are describing exactly what needs to be done. I personally don't like the hard coded string in mosys for matching, but it's something required to 'bind' the platform probe matching code in mosys.

More concretely, here's a snippet of dmidecode for phaser:

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Google
Product Name: Phaser
Version: rev1
Serial Number: 123456789
UUID: Not Settable
Wake-up Type: Reserved
SKU Number: sku2
Family: Google_Octopus

'smbios-name-match' is not the greatest name and should be changed since it's ambiguous as to what it's using. The 'Family' name in type 1 table should be used, as you noted, for a shallow probe (https://chromium-review.googlesource.com/1161190) in mosys as well as matching master config. Then, yes, one could utilize the 'oem_id' + 'sku_id' from cbi for model distinction. Currently it's using 'Product Name' which isn't terrible. Either one would work. However, we don't currently export the 'oem_id' out of the EC in a more convenient place. Because of that ectool would need to be invoked to gather that information every time. I think that's something that should be looked into.

In order to do that we need new fields:
1. Indicate how to match family: both method and string
2. in the model-specific section specify what to use and where to get it.

I think we're on the same page, but it's more complicated than what was initially brought up. Does all that make sense to you? Or am I missing anything?

Yes, we are on the same page for your overall conclusion after catching up the topic of how a single mosys support multiple platforms.

Your conclusion make it more flexible especially for that I had a concern about making oem_id as part of identity since not all projects are with oem id.

There is a common sub-task with b/115062570 which is to expose EEPROM values into userspace (e.g. via sysfs node). I can try to contribute it.