meson: reformat with meson formatter

Apply the `meson format` results.

Change-Id: Iab5fdd6b41eab1cc138df39f1dce5345bf260306
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

Detect how many address bytes needed for a given EEPROM memory

Introduce different modes to detect how many address byte(s) needed
for a given EEPROM device.

MODE_1:
-------
The existing upstream f

Detect how many address bytes needed for a given EEPROM memory

Introduce different modes to detect how many address byte(s) needed
for a given EEPROM device.

MODE_1:
-------
The existing upstream function isDevice16Bit() bases on sending
1-byte write operation (with a STOP condition) and 8 subsequent
1-byte read operations with SINGLE byte address.

1. This MODE_1 expects the following logic:
- if the device requires 1 address byte, it EXPECTS that the data
will be read from a single location so 8 bytes read will be the
same.
- if the device requires 2 address bytes, it EXPECTS that the data
will be read from 8 DIFFERENT LOCATIONS and at least one byte
read is different than 7 other reads.

2. Issue and potential issue with this MODE_1
- If any "2 address bytes" EEPROM from any vendor has the same data
in all memory locations (0-7) the existing upstream function read,
this device will be identified as "1 address byte" device.
- ONSEMI EEPROM (a 2 address bytes device) return the same data from
the same single byte address read --> therefore, existing function
wrongly identifies it as 1 byte address device.

MODE_2:
-------
The proposal MODE_2 changes to isDevice16Bit() sends 8 instructions
of 2-bytes write operation (WITHOUT a STOP condition ie. prohibited
STOP) followed by a 1-byte read operation. The proposed solution
fully complies with

IIC standard and should be applicable to any IIC EEPROM manufacturer.

| Start | SlaveAddr + W | 0x00 | 0x00 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |
|-------|---------------|------|------|----------------------|-------|
--------------|-----------|------|
| Start | SlaveAddr + W | 0x00 | 0x01 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |
| Start | SlaveAddr + W | 0x00 | 0x02 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |
| Start | SlaveAddr + W | 0x00 | 0x03 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |
| Start | SlaveAddr + W | 0x00 | 0x04 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |
| Start | SlaveAddr + W | 0x00 | 0x05 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |
| Start | SlaveAddr + W | 0x00 | 0x06 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |
| Start | SlaveAddr + W | 0x00 | 0x07 | STOP PROHIBITED HERE | Start |
SlaveAddr + R | data byte | Stop |

1. If the device requires a single data byte, then it will always
load address 0x00, so the subsequent read byte will be the same for
all 8 instructions. The second byte on the write would be interpreted
as data byte, thus not modifying the address pointer.

2. If two address bytes are required, then the device will interpret
both bytes as addresses, thus reading from different addresses every
time, similar with what the existing function is using now.

Notes & reasons:
-----------------
There is no STOP condition after the second (potential) address byte.
A START condition must be sent after the second byte.
If STOP condition is sent, then the 1-byte address devices will start
internal write cycle, altering the EEPROM content which is not good.

This proposal MODE_2 suffers the same 1st issue (#2a) as before (what
if the EEPROM has the same data at all those addresses).
However, this proposal MODE_2 addresses the 2nd issue (#2b)
where existing MODE_1 upstream function EXPECTS that the data will
be read from 8 DIFFERENT LOCATIONS if the device requires 2 address
bytes. This expectation is the ambiguity (not standard defined) in
the IIC spec
(https://www.nxp.com/docs/en/user-guide/UM10204.pdf)

1. Section 3.1.10, Note 2 -> "All decisions on auto-increment or
decrement of previously accessed memory locations, etc., are taken by
the designer of the device."
Based on this note, the designer of every EEPROM has the "freedom"
to use whatever architecture considers appropriate and suitable to
process everyone of the two address bytes. There are no restrictions
on this.

Based on this, the others EEPROM (not ONSEMI EEPROM) auto-increment -
observed with one address byte sent instead of two - is a
manufacturer-specific behavior, and not standard defined.

2. Section 3.1.10, Note 1 -> "Combined formats can be used, for
example, to control a serial memory. The internal memory location
must be written during the first data byte. After the START
condition and slave address is repeated, data can be transferred."

This proposal MODE_2 implements this note. The memory location
referred herein is the address pointer, as being the first data
byte in I2C communication. Based on this note, EEPROM must update
this pointer immediately following this first address byte.

Tested:
--------
1. With ONSEMI I2C eeprom memory on Nvidia Bluefield-3 HCA
a. Without this patch or with this patch MODE_1

root@dpu-bmc:~# ipmitool fru
FRU Device Description : Builtin FRU Device (ID 0)
Device not present (Requested sensor, data, or record not found)

FRU Device Description : Nvidia-BMCMezz (ID 169)
Board Mfg Date : Thu May 11 13:00:00 2023 UTC
Board Mfg : Nvidia
Board Product : Nvidia-BMCMezz
Board Serial : MT2319XZ04K6
Board Part Number : 900-9D3B6-00CV-AA0

b. With this patch MODE_2

root@dpu-bmc:~# ipmitool fru
FRU Device Description : Builtin FRU Device (ID 0)
Chassis Type : Main Server Chassis
Chassis Part Number : 900-9D3B6-00CV-AA0
Chassis Serial : MT2319XZ04K6
Chassis Extra : N/A
Chassis Extra : N/A
Chassis Extra : N/A
Chassis Area Checksum : OK
Board Mfg Date : Thu May 11 13:00:00 2023 UTC
Board Mfg : N/A
Board Product : N/A
Board Serial : MT2319XZ04K6
Board Part Number : 900-9D3B6-00CV-AA0
Board Extra : N/A
Board Area Checksum : OK
Product Manufacturer : N/A
Product Name : N/A
Product Part Number : 900-9D3B6-00CV-AA0
Product Serial : MT2319XZ04K6
Product Asset Tag : N/A
Product Extra : N/A
Product Area Checksum : OK

FRU Device Description : Nvidia-BMCMezz (ID 169)
Board Mfg Date : Thu May 11 13:00:00 2023 UTC
Board Mfg : Nvidia
Board Product : Nvidia-BMCMezz
Board Serial : MT2319XZ04K6
Board Part Number : 900-9D3B6-00CV-AA0
Board Area Checksum : OK

2. With other I2C eeprom memory on Nvidia Bluefield-3 HCA, and
without this patch or with this patch on both MODE_1/MODE_2

root@dpu-bmc:~# ipmitool fru
FRU Device Description : Builtin FRU Device (ID 0)
Chassis Type : Main Server Chassis
Chassis Part Number : 900-9D3B4-00EN-EAA
Chassis Serial : MT2315XZ0599
Chassis Extra : N/A
Chassis Extra : N/A
Chassis Extra : N/A
Chassis Area Checksum : OK
Board Mfg Date : Tue Apr 18 10:25:00 2023 UTC
Board Mfg : N/A
Board Product : N/A
Board Serial : MT2315XZ0599
Board Part Number : 900-9D3B4-00EN-EAA
Board Extra : N/A
Board Area Checksum : OK
Product Manufacturer : N/A
Product Name : N/A
Product Part Number : 900-9D3B4-00EN-EAA
Product Version : N/A
Product Serial : MT2315XZ0599
Product Asset Tag : N/A
Product Extra : N/A
Product Area Checksum : OK

FRU Device Description : Nvidia-BMCMezz (ID 169)
Board Mfg Date : Tue Apr 18 10:25:00 2023 UTC
Board Mfg : Nvidia
Board Product : Nvidia-BMCMezz
Board Serial : MT2315XZ0599
Board Part Number : 900-9D3B4-00EN-EAA
Board Area Checksum : OK

Change-Id: I296c22334c919f4248fb3a7f19e384ce802cba17
Signed-off-by: Vu Pham <vuhuong@nvidia.com>

show more ...

service: device-tree node vpd to d-bus hw id data

A daemon for transferring Viable Product Data (VPD) from device-tree
nodes to D-Bus as described in the design doc @
https://gerrit.openbmc.org/c/op

service: device-tree node vpd to d-bus hw id data

A daemon for transferring Viable Product Data (VPD) from device-tree
nodes to D-Bus as described in the design doc @
https://gerrit.openbmc.org/c/openbmc/docs/+/66369

and discussed in this Technical Oversight Forum topic @
https://github.com/openbmc/technical-oversight-forum/issues/38

Tested:
Ensure 'model' and/or 'serial-number' nodes are populated in
/proc/device-tree. Can be hardcoded into platform DTS via
linux-kernel recipe if needed.

'''
After OBMC boot, calling
> busctl introspect xyz.openbmc_project.MachineContext /xyz/openbmc_project/MachineContext

produces the following output:

NAME TYPE SIGNATURE RESULT/VALUE FLAGS
...
xyz.openbmc_project.Inventory.Decorator.Asset interface - - -
.BuildDate property s "" emits-change writable
.Manufacturer property s "" emits-change writable
.Model property s "hpe,dl360" emits-change writable
.PartNumber property s "" emits-change writable
.SerialNumber property s "t5texpl" emits-change writable
...

Note: Writing to one of these properties will update the property on D-Bus without affecting the
underlying device-tree node. An 'updated' event will be fired, so Entity-Manager probes monitoring
a given property would recognize the new value and key off it.
'''

Change-Id: Id52d1fc3b26010c864c7e64d3dfdf0a2b5de9294
Signed-off-by: Chris Sides <Christopher.Sides@hpe.com>

show more ...

meson: use phosphor-logging for debug statements

There is no need to individually patch each file to enable debug
logging.

All the different definitions of 'bool debug' are removed in favor of
usin

meson: use phosphor-logging for debug statements

There is no need to individually patch each file to enable debug
logging.

All the different definitions of 'bool debug' are removed in favor of
using phosphor-logging.

Change-Id: Ia9a8ecfa4ea220f588d7cf2d291b14067e0391e7
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>

show more ...

meson: change install_dir to /usr/libexec/entity-manager

We notice a issue that if user accidentally execute fru-device and
terminate it after few second, the xyz.openbmc_project.FruDevice
busname w

meson: change install_dir to /usr/libexec/entity-manager

We notice a issue that if user accidentally execute fru-device and
terminate it after few second, the xyz.openbmc_project.FruDevice
busname will not exist on dbus, but the status of FruDevice.service is
still active running.

It because sdbusplus changes the behavior of request_name() and it
allows the busname can be replaced by new service. [1]

In order to avoid unexpected behavior by running service binary
accidentally, move the install_dir to /usr/libexec/entity-manager.

Tested result:
- EntityManager is still running normally after the change
```
root@bmc:~# systemctl status xyz.openbmc_project.EntityManager.service
● xyz.openbmc_project.EntityManager.service - Entity Manager
Loaded: loaded (/usr/lib/systemd/system/xyz.openbmc_project.EntityManager.service; enabled; preset: enabled)
Active: active (running) since Wed 2024-03-20 23:25:44 PDT; 27min ago
Process: 596 ExecStartPre=/bin/mkdir -p /var/configuration (code=exited, status=0/SUCCESS)
Process: 679 ExecStartPre=/bin/mkdir -p /tmp/overlays (code=exited, status=0/SUCCESS)
Main PID: 687 (entity-manager)
CPU: 7.203s
CGroup: /system.slice/xyz.openbmc_project.EntityManager.service
└─687 /usr/libexec/entity-manager/entity-manager
```
- FruDevice is still running normally after the change
```
root@bmc:~# systemctl status xyz.openbmc_project.FruDevice.service
● xyz.openbmc_project.FruDevice.service - Fru Device
Loaded: loaded (/usr/lib/systemd/system/xyz.openbmc_project.FruDevice.service; enabled; preset: enabled)
Active: active (running) since Wed 2024-03-20 23:25:40 PDT; 28min ago
Main PID: 598 (fru-device)
CPU: 729ms
CGroup: /system.slice/xyz.openbmc_project.FruDevice.service
└─598 /usr/libexec/entity-manager/fru-device
```

[1] https://github.com/openbmc/sdbusplus/commit/946c940434a7d5403f469ce2ab56f9136293ff38

Signed-off-by: Potin Lai <potin.lai@quantatw.com>
Change-Id: I01c1f0fe7a1bdbaf74ec4d080b62450f4a90a057

show more ...

Align source structure away from anti-patterns

The anti-patterns document comments on source structure, specifically on
placing internal headers in a parallel subtree[1]. entity-manager is an
exampl

Align source structure away from anti-patterns

The anti-patterns document comments on source structure, specifically on
placing internal headers in a parallel subtree[1]. entity-manager is an
example of violating this anti-pattern, so fix it.

[1]: https://github.com/openbmc/docs/blob/master/anti-patterns.md#placing-internal-headers-in-a-parallel-subtree

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Change-Id: I6c9739d1d532ea670e5ceb30044017c38e49eed3

show more ...

topology: integrate with entity-manager

In the exposes loop, add information about each board to the topology
object including the path, board type, and what item is being exposed.
At the end, retri

topology: integrate with entity-manager

In the exposes loop, add information about each board to the topology
object including the path, board type, and what item is being exposed.
At the end, retrieve the resulting associations from the topology object
and post those to D-Bus.

Tested:
With minimal example JSON configs for two boards, was able to query the
expected associations from the mapper.

Signed-off-by: Benjamin Fair <benjaminfair@google.com>
Change-Id: If050e243ac5dc39c540704b7536f7f792897f17c

show more ...

fru-device: add FRUReader EEPROM cache

This doesn't provide a huge benefit currently, but is a preparatory step
for adding support for a wider variety of FRU format parsers. If
parsers for multiple

fru-device: add FRUReader EEPROM cache

This doesn't provide a huge benefit currently, but is a preparatory step
for adding support for a wider variety of FRU format parsers. If
parsers for multiple formats are interested in reading the same areas of
an EEPROM, the caching provided by this abstraction avoids the redundant
bus traffic of all of them re-reading the same bytes over and over.

Tested: on an ASRock Rack romed8hm3, fru-device successfully recognizes
and parses the baseboard FRU EEPROM as it did prior to this patch.

Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Change-Id: I0d774508bc29dbda346309fe7fe42dbdf97bee43

show more ...

treewide: comply with the OpenBMC style guidelines

The guidelines say cpp source code filenames should be lower_snake_case:
https://github.com/openbmc/docs/blob/master/cpp-style-and-conventions.md#f

treewide: comply with the OpenBMC style guidelines

The guidelines say cpp source code filenames should be lower_snake_case:
https://github.com/openbmc/docs/blob/master/cpp-style-and-conventions.md#files

Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
Change-Id: Ia04017b0eb9a65ce1303af5b6dc36e730410fd91

show more ...

meson: nlohmann/json has a meson build

Exploit the usual configuration available for subprojects that support
meson directly.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Change-Id: Ifef98dc70a2

meson: nlohmann/json has a meson build

Exploit the usual configuration available for subprojects that support
meson directly.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Change-Id: Ifef98dc70a24f41df1b199fcbf28fe034a5526bc

show more ...

Utils: Break out expression parsing and evaluation

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Change-Id: I16101a37220be56722cedd273d5788393aa860fa

entity-manager: Search sysconfdir for configurations

Make it easier to iteratively develop configurations in-place with a
read-only /usr.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Change-Id:

entity-manager: Search sysconfdir for configurations

Make it easier to iteratively develop configurations in-place with a
read-only /usr.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Change-Id: Id0853b579a61394cb2b6ef0a3858ba01e5cb2893

show more ...

EntityManager: Split out PerformProbe

Continue breaking down the code so regular people can comprehend it.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Change-Id: Ic4458054df7426d579cb99dd21f357

EntityManager: Split out PerformProbe

Continue breaking down the code so regular people can comprehend it.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Change-Id: Ic4458054df7426d579cb99dd21f3578d1265711d

show more ...

EntityManager: Split out PerformScan

Start breaking down the code so regular people can comprehend it.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Change-Id: I82fec105fbe29bd09145feaaa48fbcb875

EntityManager: Split out PerformScan

Start breaking down the code so regular people can comprehend it.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Change-Id: I82fec105fbe29bd09145feaaa48fbcb875ca930f

show more ...

Revert "meson: nlohmann/json has a meson build"

and Revert "meson: Rework valijson subproject dependency"

This reverts commit 9fedd141288d36d41345305532251e4659535751.
and e7948f447eaeb3afaa78d5d29

Revert "meson: nlohmann/json has a meson build"

and Revert "meson: Rework valijson subproject dependency"

This reverts commit 9fedd141288d36d41345305532251e4659535751.
and e7948f447eaeb3afaa78d5d298dc12b0730b8a84.

As they break the yocto build.

Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I8034a362f0866342a1527f468dc84a6ff1c67bd7

show more ...

meson: nlohmann/json has a meson build

Exploit the usual configuration available for subprojects that support
meson directly.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Change-Id: I410cc14ca42

meson: nlohmann/json has a meson build

Exploit the usual configuration available for subprojects that support
meson directly.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Change-Id: I410cc14ca426b1c4c26600f6a72a47aa4d944570

show more ...

split readFRUContents() into FruUtils module

Splits the readFRUContents() method into its own module. This utility
code can then be more easily tested without extra dependencies.

Signed-off-by: Pa

split readFRUContents() into FruUtils module

Splits the readFRUContents() method into its own module. This utility
code can then be more easily tested without extra dependencies.

Signed-off-by: Patrick Venture <venture@google.com>
Change-Id: I1b8fa7179d7d0092e0236e8586f99c45121eca84

show more ...

FruDevice: improve updateFRUProperty function

updateFRUProperty function is used to write ASSET field but it
pretended to be generic.

This change fixes number of issues like
* wrong size check
* no

FruDevice: improve updateFRUProperty function

updateFRUProperty function is used to write ASSET field but it
pretended to be generic.

This change fixes number of issues like
* wrong size check
* no control of data overflow
* erase FRU Area next to updated area
* wrong handle of first/last fields in area
and some other
This change also implements functionality to resize FRU Area, but it is
disabled by default.

Tested: Tested by setting all properties as writable ad then trying to
change them using "set-property" busctl call to FruDevice.

Signed-off-by: Andrei Kartashev <a.kartashev@yadro.com>
Change-Id: Ic049bbf591878b4af344a352a2bec296e70cfb6e

show more ...

meson: Add fru-device-less build configuration

Provide an option that skips building of fru-device. fru-device remains
enabled and built by default.

Change-Id: If927861cf70aaf594844e28e993edc30813

meson: Add fru-device-less build configuration

Provide an option that skips building of fru-device. fru-device remains
enabled and built by default.

Change-Id: If927861cf70aaf594844e28e993edc308138ddf2
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>

show more ...

meson: add support for valijson library vendoring

Abuse the meson subproject command to download valijson and build
against that when valijson is not found in the usual places. This
enables the bui

meson: add support for valijson library vendoring

Abuse the meson subproject command to download valijson and build
against that when valijson is not found in the usual places. This
enables the building and running of the unit tests without needing to
install valijson.

This is abuse because the subproject command will always fail - meson
only supports other meson projects as subprojects but it will download
the project, and since we don't actually build valijson but just use
headers this isn't a problem.

Change-Id: I2595b3deec73ac503934b91bdf52f72399032bcb
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>

show more ...

meson: add support for nlohmann-json vendoring

Abuse the meson subproject command to download nlohmann and build
against that when nlohmann is not found in the usual places. This
enables building a

meson: add support for nlohmann-json vendoring

Abuse the meson subproject command to download nlohmann and build
against that when nlohmann is not found in the usual places. This
enables building and running of the unit tests without needing to
install nlohmann.

This is abuse because the subproject command will always fail - meson
only supports other meson projects as subprojects but it will download
the project, and since we don't actually build nlohmann but just use
headers this isn't a problem.

Change-Id: I3cff76f8face3ebe66611d169775b472c18b1e4c
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>

show more ...

Add support for building with meson

Follow the OpenBMC herd and support a modern, comprehensible build
framework.

To build with meson:
meson build
ninja -C build

Add -Dtests to match de-facto

Add support for building with meson

Follow the OpenBMC herd and support a modern, comprehensible build
framework.

To build with meson:
meson build
ninja -C build

Add -Dtests to match de-facto OpenBMC meson usage conventions.

After this patch existing unit tests continue to pass.

One noteable omission is support for subprojects or vendoring. Cmake
support, with subproject vendoring remains.

The OpenBMC CI scripts look for meson.build before looking for
CMakelists so approval of this patch would change the build system
during CI to meson.

Change-Id: I3d08e37d8c39ed2eecc4245671fb84ce6e3bc279
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>

show more ...