Update .md files to reflect Ubuntu version change used for testing

Signed-off-by: Nikhil Raj <nikhil.raj@arm.com>
Change-Id: I9b5407a2d6fc27df2c448a4f6a6b862d2175022c

3 files changed, 2 insertions, 6 deletions

diff --git a/BuildGuideAndroidNDK.md b/BuildGuideAndroidNDK.md
index 3dd96b8a78..3408ec1326 100644
--- a/BuildGuideAndroidNDK.md
+++ b/BuildGuideAndroidNDK.md
@@ -11,7 +11,7 @@
 
 ## Introduction
 These are step by step instructions for using the Android NDK to build Arm NN.
-They have been tested on a clean install of Ubuntu 16.04 and 18.04, and should also work with other OS versions.
+They have been tested on a clean install of Ubuntu 18.04, and should also work with other OS versions.
 The instructions show how to build the Arm NN core library.
 Building protobuf is optional. We have given steps should the user wish to build it (i.e. as an Onnx dependency).
 All downloaded or generated files will be saved inside the `$HOME/armnn-devenv` directory.
diff --git a/BuildGuideCrossCompilation.md b/BuildGuideCrossCompilation.md
index 72f7f02f62..d70f1ca4f1 100644
--- a/BuildGuideCrossCompilation.md
+++ b/BuildGuideCrossCompilation.md
@@ -15,7 +15,7 @@
 
 
 ## Introduction
-These are the step by step instructions on Cross-Compiling Arm NN under an x86_64 system to target an Arm64 system. This build flow has been tested with Ubuntu 16.04 and it depends on the same version of Ubuntu or Debian being installed on both the build host and target machines. The instructions assume you are using a bash shell and show how to build the Arm NN core library, Protobuf, Tflite, Flatbuffer and Compute Libraries.
+These are the step by step instructions on Cross-Compiling Arm NN under an x86_64 system to target an Arm64 system. This build flow has been tested with Ubuntu 18.04 and it depends on the same version of Ubuntu or Debian being installed on both the build host and target machines. The instructions assume you are using a bash shell and show how to build the Arm NN core library, Protobuf, Tflite, Flatbuffer and Compute Libraries.
 Start by creating a directory to contain all components:
 
 '''
diff --git a/docs/FAQ.md b/docs/FAQ.md
index f80c1ea22b..6771e50f19 100644
--- a/docs/FAQ.md
+++ b/docs/FAQ.md
@@ -32,10 +32,6 @@ Many DynamicBackendTests fail with "Base path for shared objects does not exist"
 ---------------------------------------------------------
 This problem most commonly occurs when the compile and runtime environments for the unit tests differ. These dynamic backend tests rely on a set of test files and directories at runtime. These files are created by default during the cmake build. At runtime the tests will look for these files in src/backends/backendsCommon/test/ relative to where the Unittests executable was built. The usual solution to to copy these files and directories into the new unit test execution environment. You can also specify a new root path for these files by adding a command line parameter to the Unittests executable: Unittests -- --dynamic-backend-build-dir "new path"
 
-UnitTests executable exits with "corrupted size vs. prev_size" in armv7 environments.
----------------------------------------------------------
-Some combinations of GCC cross compiler and pthread runtime in an armv7 environment result a UnitTests executable that will raise SIGABRT signals. The exact combination has not been identified but it is known that cross compiling on Ubuntu 16.04 for an armv7 environment does exhibit this behavior. It is possible to exclude unit tests that use the pthread library using the Boost exclude mechanism, '--run_test=![filter expression]'. The list of tests that might cause this problem is constantly increasing. Consideration should be given to using a newer build environment.
-
 UnitTests fail on Max OS-X with errors in boost::program_options
 ---------------------------------------------------------
 When executing Arm NN UnitTests built in an OS-X environment, runtime errors occur around boost::program_options. When compiling boost the "b2" tool appears to have a bug where it defaults to using the native ranlib even when the correct tool is specified in the user_config.jam.