Why do we need yaml tag? What kind of new format do we need?

BTW, if the tag is simply for encoding strings, can we introduce a more generic tag like !enum so we don't need to write more tags in future?

After tracing the mosys code, the board id is exported at
/proc/device-tree/firmware/coreboot/board-id. So we can also read this file in probe.py, instead of implementing new command in mosys.

The board_id is between 0~26, so need a field to record each of them.
!board_id_component should be like:
items:
  '0':
    values:
      board_id: '0'
  '1':
    values:
      board_id: '1'
  ...
  '26':
    values:
      board_id: '26'

If we use the general tag like !enum to replace the specific tags, we should assign the key of the probed result and the possible values. It would looks like:

components:
  region:
    !enum_components
      # Because the probed result of region is {'region_code': 'us'}
      key: region_code  
      values: ['us', 'tw']
  board_id:
    !enum_components
      key: board_id
      values: ['0', '1', '2', '3', '4']

Similarly, the general enum encoded_field would looks like:

encoded_fields:
  region_field:
    !enum_encoded_field
      component: region
      values: ['us', 'tw']
  board_id_field: 
    !enum_encoded_field
      component: board_id
      values: ['0', '1', '2', '3', '4']

Looks good?

> /proc/device-tree/firmware/coreboot/board-id

 device-tree is not available on x86, so if we'll want to include board_id, and mosys (already) haas it, we should call mosys.
 P.S: isn't that "mosys platform version" ?

Regarding the general enum, I wonder if we can minimize duplication so it looks like

components:
  region_code:
    !enum_component ['us', 'tw']
  board_id:
    !enum_component ['0', '1', '2', '3', '4']

encoded_fields:
  region_code_field:
    !enum_field
  board_id_field: 
    !enum_field

The idea is, enum_component should look at its parent to decide the key name, and store the values;
enum_field should look at its parent to find key name, and enumerate according to what we've generated in components.

Just realized that "mosys platform version" is not identical to this.

+dhendrix

Hi David, how do we define what should be printed on "mosys platform version"?

It seems like that on current implementation, x86 is reading from SMBIOS (which has a hard-coded version string), and some ARM boards read from board_id GPIO pins.

Is there a general way to read board_id that we can expect both x86 and arm will return same meaning?

Re #4: As you point out, the "version" can come from a variety of sources - SMBIOS (x86), ACPI (x86), device-tree (non-x86), coreboot tables, raw GPIO reading, etc. "mosys platform version" is supposed to abstract all those details.

However the format has always been considered to be a free-form string. Some platforms expose numbers ("X.Y" or "rev%u" formats), some expose production phases ("EVT", "DVT", etc).

Does board_id need to be an integer? Also, I suggest renaming it to "board_revision" or "board_version". "board_id" could imply other meanings such as serial number.

Re#5:
"board id" comes from the original name that we can find on schematics.
And yes, in factory side we do call it "board version" in source.

In fact I just realized that this is provided per-device. On some platform, for example samus, "mosys platform version" does tell right name.

So I think the problem now is "some boards don't specify right version info", but that's beyond the scope of this issue.

Chih-Yu, for the original request, you can reply: board_id is already provided as "board_version" in gooftool probe results. If it's always something like "1.0" then it has to be fixed in firmware, by filling right board id.

Regarding the yaml tag, I think you can still finish the implementation of generic enum tag, but that does not need to be the blocking item for original request (board_id) since I think most projects won't have too many board revisions.

Ah, yes... It seems there are a few boards (cyan, glados, strago, reef) where "mosys platform version" is not actually enabled for some reason. I'm surprised that many platforms have gone by without somebody noticing. We can investigate that further and see if we can get valid info for those boards, though as you say it's beyond the scope of this issue.

At the very least mosys commands should return ENOSYS (38) in case the command is not implemented. So you can check for that return code in gooftool and error out if needed.

> a few boards (cyan, glados, strago, reef) 

I think that's not just few since it covers probably 80% of x86 chromebooks :)

Chih-Yu: Can you provide more detail about the original request to verify board version in the HWID?

I am curious if we intend to do handle pre-MP boards in some kind of special way involving HWID. As I understand, HWID is mostly intended to identify configuration (CPU, memory config, display, etc). Adding board version adds a whole other dimension which may have large implications.

Re #9:

The original request is Terra uses a new eMMC and need to verify the device with new eMMC should use a new board ID. We can add the rule in HWID to verify the mapping of board ID and the hardware configuration is what we want. I think that's the purpose of adding board ID into HWID.

https://code.google.com/p/chrome-os-partner/issues/detail?id=58568#c21