Gitiles
Code Review Sign In
gerrit.openbmc.org / openbmc / hiomapd / 3dce83dbc3cf1830053a03a2c0e00ae43da50b19
commit3dce83dbc3cf1830053a03a2c0e00ae43da50b19[log] [tgz]
authorAndrew Jeffery <andrew@aj.id.au>Thu Mar 22 16:52:42 2018 +1030
committerAndrew Jeffery <andrew@aj.id.au>Wed Apr 04 07:56:22 2018 +0000
treeb3b677c1a5c878192767b1f2fc950775d1015b12
parentca1dfc9e902eddd8031baaaeb9dd6b3f4be4b1a2 [diff]
test: vpnor: Add dump_flash test

The test is intended to read and verify the content of the flash, and
verify that the read completes without error in the face of unusual
flash size with respect to the window configuration.

Specifically, the test is arranged such that the reserved memory exceeds
the flash size, and the flash layout conspires such that the final
request is for a window whose flash offset and window size exceed the
flash size. This currently triggers an error condition in the mbox
window handling, and causes the host to receive an error response to its
CREATE_READ_WINDOW request. On the host side this results in the reading
process receiving an EIO.

Due to what is probably an oversight in the mbox window handling, some
care needs to be taken in the test configuration: The current behaviour
is that copy_flash() will return a length that may be less than the size
of the reserved memory window. The returned value is aligned up to the
next block and assigned as the current window's size. However, when
evicting a window, we do not reset the size to the default size. As a
consequence, windows can shrink and remain at a size below the default
window size. Without careful control of the test parameters this can
lead to the appearance that there is no bug in the window handling as,
serendipitously, a window of the correct size can be evicted for the
final CREATE_READ_WINDOW request.

Change-Id: I436595f428bf4e93392315ec1110b6b6f4a11821
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
2 files changed
tree: b3b677c1a5c878192767b1f2fc950775d1015b12
  1. Documentation/
  2. m4/
  3. test/
  4. xyz/
  5. .clang-format-c
  6. .clang-format-c++
  7. .gitignore
  8. bootstrap.sh
  9. common.c
  10. common.h
  11. configure.ac
  12. dbus.h
  13. format-code.sh
  14. LICENSE
  15. Makefile.am
  16. mbox.h
  17. mboxctl.c
  18. mboxd.c
  19. mboxd_dbus.c
  20. mboxd_dbus.h
  21. mboxd_flash.h
  22. mboxd_flash_physical.c
  23. mboxd_flash_virtual.cpp
  24. mboxd_lpc.c
  25. mboxd_lpc.h
  26. mboxd_lpc_physical.c
  27. mboxd_lpc_virtual.cpp
  28. mboxd_msg.c
  29. mboxd_msg.h
  30. mboxd_pnor_partition_table.cpp
  31. mboxd_pnor_partition_table.h
  32. mboxd_windows.c
  33. mboxd_windows.h
  34. mtd.c
  35. pnor_partition.cpp
  36. pnor_partition.hpp
  37. pnor_partition_defs.h
  38. pnor_partition_table.cpp
  39. pnor_partition_table.hpp
  40. README.md
README.md

Copyright 2017 IBM

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

MBOX

This repo contains the protocol definition for the host to BMC mailbox communication specification which can be found in Documentation/mbox_procotol.md.

There is also a reference implementation of a BMC mailbox daemon, the details of which can be found in Documentation/mboxd.md.

Finally there is also an implementation of a mailbox daemon control program, the details of which can be found in Documentation/mboxctl.md.

Style Guide

Preamble

This codebase is a mix of C (due to its heritage) and C++. This is an ugly split: message logging and error handling can be vastly different inside the same codebase. The aim is to remove the split one way or the other over time and have consistent approaches to solving problems.

phosphor-mboxd is developed as part of the OpenBMC project, which also leads to integration of frameworks such as phosphor-logging. Specifically on phosphor-logging, it's noted that without care we can achieve absurd duplication or irritating splits in where errors are reported, as the C code is not capable of making use of the interfaces provided.

Rules

  1. Message logging MUST be done to stdout or stderr, and MUST NOT be done directly via journal APIs or wrappers of the journal APIs.

    Rationale:

    We have two scenarios where we care about output, with the important restriction that the method must be consistent between C and C++:

    1. Running in-context on an OpenBMC-based system
    2. Running the test suite

    In the first case it is desirable that the messages appear in the system journal. To this end, systemd will by default capture stdout and stderr of the launched binary and redirect it to the journal.

    In the second case it is desirable that messages be captured by the test runner (make check) for test failure analysis, and it is undesirable for messages to appear in the system journal (as these are tests, not issues affecting the health of the system they are being executed on).

    Therefore direct calls to the journal MUST be avoided for the purpose of message logging.

    Note: This section specifically targets the use of phosphor-logging's log<T>(). It does not prevent the use of elog<T>().