White Papers

As discussed earlier, the OEM FRU area can be used to store generic values such as Manufacturer Name and Part Number, which are

fixed and don’t change on a per server basis. Serial Numbers and similar fields, however, need to be unique per system. If the OEM

FRU contents for your solution have no server specific content, it might be easiest to create the BIN file and have it included within ID

Module.

If there are instances of unique content in the FRU or you want to allow easy change of the FRU structure over time, Dell EMC

recommends that you have a default blank OEM FRU defined in the ID Module and use one of the two approaches within the factory to

deploy the actual FRU content on each shipping system:

1. Build and deploy a unique BIN per system during factory process

1. Build a generic BIN template for the product with placeholders for unique fields

2. Deploy a generic BIN template on each system during factory process

3. Change the placeholder values to system specific values during factory process

Both approaches are available, depending on the capabilities of the factory process. However, the latter method reduces the tool

dependencies in the factory.

The first method requires a process to generate the INI file (since OEM FRU content is system specific) and Python to create the BIN

with the FRU tool. In addition, IPMItool is required to write the BIN to the server.

The second method requires only IPMItool to write the BIN and edit the system specific fields. The INI file can be hand authored. The

BIN file can be generated separately during development and it removes the dependency of running Python in the factory.

BEYOND INVENTORY AND TRACKING

We have seen how the OEM FRU storage area enables OEM customers to effectively inventory and track their products built on Dell

EMC PowerEdge servers. However, this storage space built into the hardware also allows for other interesting use cases.

Given the OEM FRU has 1024 bytes of space available, it is possible to use the Internal Area section to store extended information

beyond what is defined within the FRU specification. One example would be to store configuration data that is application specific. An

OEM application running on the host could load this content and change its behavior based on the configuration contained within that

file.

Another example is to use this space to hardware activate an application running on the server similar to how Microsoft enables OEM

activation for its Windows operating systems. This would allow an OEM to license the software that runs on the server without having to

distribute and manage license keys to their end customers.

The application would use the IPMItool fru read command to pull the FRU contents, extract the Internal Area section and use it to

change its behavior or limit the functionality. The content could be signed by using Public Key cryptography to verify the authenticity of

the content and be tied to the server by using unique fields such as Service Tag, serial numbers or MAC addresses to ensure that the

license cannot be moved from one server to another.

Such a hardware activation mechanism could be achieved as follows:

FACTORY PROCESS

1. Create an application license file based on what the customer purchased, such as Bit mask, INI file, JSON, and XML. The

contents of the file should instruct the application to enable/disable specific features or feature tiers.

2. Add server unique identity fields into the license file.

 The IPMItool print command lists all FRUs on the system