[Trac #1050] Need new board ID mechanism

[Zarro Boogs per Child]

#1050: Need new board ID mechanism
-------------------------------+--------------------------------------------
 Reporter:  wmb at firmworks.com  |        Owner:  wad     
     Type:  defect             |       Status:  assigned
 Priority:  high               |    Milestone:  BTest-3 
Component:  hardware           |   Resolution:          
 Keywords:                     |  
-------------------------------+--------------------------------------------
Changes (by wmb at firmworks.com):

 * cc: wmb at firmworks.com (added)

Comment:

 Is there an EC command whereby the CPU can read the EC board ID?

 I have no problem in principle with using the EC ID, but if we do it, we
 need to be careful that things don't fall through the cracks due to lack
 of communication, as so many EC-related things seem to do.

 We would need:

 * A command to read the ID.

 * A specification for the values that command can return (how many bits,
 etc)

 * A plan for how the analog voltage levels would change as boards are
 revised, with the corresponding binary values that the board ID returns.

 * The board ID value set should be ordered in some straightforward way, so
 that software can make decisions based not only on specific ID values, but
 also on "revision X or later" criteria.

 We will also need to hold open the possibility of using the IDE lines or
 the GNT lines just in case we eventually have a change severe enough that
 we must know it in very early startup code, before all of the MSRs are set
 up.

 And we also might need that as an extension mechanism if we run out of
 resolution on the analog method (i.e. use up all the values).

 We should make a decision on this very soon.

-- 
Ticket URL: <http://dev.laptop.org/ticket/1050#comment:4>
One Laptop Per Child <http://laptop.org/>