blob: 241b625a00ef05800378b6ece26de29095f10668 [file] [log] [blame]
Zane Shelley5a266612019-08-15 16:23:53 -05001/**
2 * @file hei_main.hpp
3 *
4 * These are the primary APIs for Hardware Error Isolation (aka the isolator).
5 * The intended flow is to:
6 *
7 * - Call initialize() for each necessary Chip Data File.
8 *
9 * - Call isolate() for each chip that needs error isolation.
10 *
11 * - Once isolation is no longer needed, call uninitialize() to free up
12 * resources used for isolation.
13 *
14 * Note that initialize() allocates many objects used for isolation and keeps
15 * them in memory. Its purpose is to avoid initializing the objects each time
16 * isolation is required. The data provided by the Chip Data Files is static.
17 * So reinitializing would be a waste of time, unless for some reason the Chip
18 * Data Files themselves are updated, which would require reinitialization
19 * anyway. Of course, leaving the object in memory chews up resources. So, some
20 * users may need to weigh performance vs. memory usage.
21 */
22
23#pragma once
24
25#include <hei_includes.hpp>
26#include <hei_isolation_data.hpp>
27#include <isolator/hei_isolator.hpp>
28
29namespace libhei
30{
31
32/**
33 * @brief Initializes all isolation objects based on data from the given Chip
34 * Data File.
35 *
36 * This function only takes one Chip Data File at a time. Therefore, the
37 * user application must call this function for each Chip Data File required
38 * for isolation.
39 *
40 * Storage and management of the Chip Data Files will vary per user application.
41 * Therefore, the user application is responsible for loading the Chip Data
42 * Files into memory as needed, and providing the location and size of the data.
43 *
44 * Once this function returns, the Chip Data File is no longer needed in memory.
45 *
46 * Details of the Chip Data File format can be found in CHIP_DATA.md.
47 *
48 * @param i_buffer A pointer to the buffer containing a single Chip
49 * Data File.
50 *
51 * @param i_bufferSize The size (in bytes) of the target Chip Data File.
52 *
53 * @param i_forceInit It is possible the user application could call this
54 * function for a chip type that has already been
55 * initialized. This is useful if for some reason the Chip
56 * Data File for a specific chip type has been updated. If
57 * this function is called and a chip type has already been
58 * initialized:
59 * - false (default), the function will return
60 * RC_CDF_INITIALIZED and exit.
61 * - true, the function will delete the previous isolation
62 * objects for this chip type and reinitialize.
63 *
64 * @return RC_SUCCESS or RC_CDF_INVALID or RC_CDF_INITIALIZED
65 */
66inline ReturnCode initialize( void * i_buffer, size_t i_bufferSize,
67 bool i_forceInit = false )
68{
69 return Isolator::getSingleton().initialize( i_buffer, i_bufferSize,
70 i_forceInit );
71}
72
73/**
74 * @brief Deletes all internal isolation objects that were created by
75 * initialize().
76 */
77inline void uninitialize()
78{
79 Isolator::getSingleton().uninitialize();
80}
81
82/**
83 * @brief Isolates all active hardware errors found on the given chip.
84 *
85 * This functions requires initialize() to be called with the Chip Data File
86 * corresponding to the given chip type.
87 *
88 * @param o_isoData This parameter will contain a reference to the target chip
89 * and its chip type. The rest of the data in the object will
90 * be flushed and then repopulated with a list of all active
91 * hardware errors on this chip, the contents of any
92 * registers associated with the active errors, and any
93 * other data that can be useful for debug.
94 *
95 * @return RC_SUCCESS or RC_CHIP_DATA_MISSING
96 */
97inline ReturnCode isolate( IsolationData & o_isoData )
98{
99 return Isolator::getSingleton().isolate( o_isoData );
100}
101
102} // end namespace libhei
103