Add automated tests that:
- test that mkl_dnn shared libraries and headers can be used to
compile mkl_dnn sample application and execute it
- test that mkl_dnn various api (eg. convolution, deconv, rnn, etc)
are executable
- add extra packages checking for test compiling mkldnn application
Signed-off-by: Yeoh Ee Peng <ee.peng.yeoh@intel.com>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Add sanity tests for inference engine:
- test inference engine c/cpp shared library
- test inference engine python api
- test inference engine cpu, gpu, myriad plugin
Add sanity tests for model optimizer
- test model optmizer can generate ir
Licenses:
- classification_sample.py
license: Apache 2.0
source: <install_root>/deployment_tools/inference_engine/samples/*
Signed-off-by: Yeoh Ee Peng <ee.peng.yeoh@intel.com>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
With iucode-tool, identified the selected microcode to be used for
microcode update by the specific processor. Compared the updated
microcode from dmesg to the selected microcode, test failed if the
updated microcode revision does not match the available selected
microcode revision from the iucode-tool. Compute int from hexadecimal
for comparison based on Naveen Kumar suggestion.
Signed-off-by: Yeoh Ee Peng <ee.peng.yeoh@intel.com>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
This was based on the secureboot selftests in meta-refkit:
3bf04941a3/meta-refkit/lib/oeqa/selftest/cases/secureboot.py
It had to be modified a bit to work in meta-intel, as we can't depend on
efivar which resides in meta-openembedded. Instead, in order to test
that secureboot is enabled, we first try to boot with an unsigned, then
image signed with incorrect keys, and search for a "Security Violation"
error message in each log. If the image booted successfully or that
error did not occur, something went wrong and the third test becomes
invalid. The third test is simply booting an image that is signed with
the enrolled keys, getting to a login screen and running a simple
command.
Note that these tests can be quite time consuming, as we have to wait
for the first two tests to timeout, and the timeout values have to be
somewhat high as it sometimes takes a while for the ovmf firmware to
come up.
Original work by Mikko Ylinen and Patrick Ohly.
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
