1# OpenBMC MRW Requirements 2 3This document describes the data requirements that OpenBMC has on the machine 4readable workbook XML generated by 5[Serverwiz2](https://www.github.com/open-power/serverwiz). The requirements in 6this document are broken up by the OpenBMC functions that use them. 7 8If a particular OpenBMC implementation doesn't use a certain function, then that 9MRW data isn't required. 10 11## System Inventory 12 13The system inventory can be generated from the MRW XML. The inventory typically 14contains all FRUs (field replaceable units), along with a few non-FRU entities, 15like the BMC chip and processor cores. 16 17To specify a target in the MRW should be in the inventory: 18 19- Set the `FRU_NAME` attribute of that target. 20 21**Note**: The BMC and cores will be automatically added without the need to set 22`FRU_NAME`. 23 24## BMC Device Tree 25 26The BMC device tree can be generated from the MRW XML. For the full device tree 27to be generated, all of the corresponding devices and connections must be 28modeled in the MRW XML. For a system built with parts that already have existing 29XML representations, there are only a few attributes that need to be set. If a 30new part is being modeled, initial values for some attributes may need to be 31determined, depending on the part. 32 33The following sections list the system dependent information that the device 34tree generator requires. The majority of the information it requires is static 35data that is either already built into the XML representations of the existing 36parts or pulled in from an include file. 37 38### System Level Attributes 39 40#### `SYSTEM_NAME` 41 42The name of the system as the firmware would know it. 43 44#### MANUFACTURER 45 46The system manufacturer. 47 48### BMC Chip 49 50All of the BMC chip attributes that are needed for the device tree are pre-built 51into the XML representation and don't need to be updated when the device is 52placed into a system in Serverwiz. 53 54> Note: The AST2500 is currently the only BMC XML model that contains all of the 55> necessary device tree attributes. 56 57### BMC SPI Flashes 58 59The device tree can support either 1 or 2 BMC SPI flash chips. This is 60accomplished by connecting instances of the `BMC_FLASH` part to the 61spi-master-unit on the BMC that has its `SPI_FUNCTION` attribute set to 62`BMC_CODE`. If there are multiple chips, they are both connected to the same 63unit. 64 65### Ethernet MAC Units 66 67To enable a BMC MAC module, its ethernet master unit in the MRW must be 68connected to an ethernet slave unit. Additionally, the following attributes may 69need to be set. 70 71#### `NCSI_MODE` 72 73This attribute in the ethernet master unit can be set to 1 if the link uses 74NCSI. The default is 0. 75 76#### `USE_HW_CHECKSUM` 77 78This attribute in the ethernet master unit can be set to 1 if the MAC has 79hardware checksum enabled, or 0 if not enabled. The default is 1. 80 81### UARTS 82 83UARTs are enabled by connecting the appropriate UART master units in the BMC 84part to their corresponding uart slave units. No additional attributes are 85required. 86 87### LEDs 88 89LEDS will be listed in the device tree when LED parts in the MRW are wired to 90their GPIO master endpoints. The instance name in the MRW is the name of its 91node in the device tree. 92 93#### `ON_STATE` 94 95Set to the logic value required to activate the LED - either 0 or 1. The default 96is 0. 97 98### I2C 99 100I2C devices are enabled by connecting the I2C master units in the BMC to the I2C 101slave units on the devices. 102 103#### `I2C_ADDRESS` 104 105The 8 bit hexadecimal I2C address should be set in the slave unit of the end 106device. 107 108#### `BMC_DT_COMPATIBLE` 109 110When creating a new XML device model, this attribute should be used to specify 111which device driver the kernel will use to access the device. For example, 112`ti,423` or `bosch,bmp280`. For existing parts, this should already be set. 113 114#### `BMC_DT_ATTR_NAMES` 115 116This attribute is also only required when creating a new XML representation of 117an I2C device. It specifies which other attributes of the device should be 118listed as properties in the device tree, as required by the device driver for 119that device. It can contain up to 4 pairs of names, the first name in the pair 120is the attribute name in the XML to read, and the second name in the pair is the 121name of the property to call it in the device tree. For example, 122`ATTR_WRITE_PAGE_SIZE, pagesize` indicates that the value of the 123`ATTR_WRITE_PAGE_SIZE` attribute should be stored in a property called 124`pagesize` in the device tree. 125