Arm® TBSAv8 M Architecture Validation Methodology And User Guide Arm TBSA V8M Arch

User Manual:

Open the PDF directly: View PDF .
Page Count: 30

Download
Open PDF In Browser	View PDF

Arm® TBSAv8-M Architecture Test
Revision: r0p0

Validation Methodology and User Guide

Arm® TBSAv8-M Architecture Test

Arm® TBSAv8-M Architecture Test
Validation Methodology and User Guide
Copyright © 2018 Arm Limited or its affiliates. All rights reserved.
Release Information

Document History
Issue

Date

Confidentiality Change

PJDOC-2042731200-3327 March 2018

Confidential

Pre alpha release

PJDOC-2042731200-3327 March 2018

Confidential

Alpha release

0000-01

15 June 2018 Non-Confidential Dev0.5 release. Note: The document now follows a
new numbering format.

0000-02

29 June 2018 Non-Confidential Dev0.6 release.

Non-Confidential Proprietary Notice
This document is protected by copyright and other related rights and the practice or implementation of the information contained in
this document may be protected by one or more patents or pending patent applications. No part of this document may be
reproduced in any form by any means without the express prior written permission of Arm. No license, express or implied, by
estoppel or otherwise to any intellectual property rights is granted by this document unless specifically stated.
Your access to the information in this document is conditional upon your acceptance that you will not use or permit others to use
the information for the purposes of determining whether implementations infringe any third party patents.
THIS DOCUMENT IS PROVIDED “AS IS”. ARM PROVIDES NO REPRESENTATIONS AND NO WARRANTIES,
EXPRESS, IMPLIED OR STATUTORY, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
MERCHANTABILITY, SATISFACTORY QUALITY, NON-INFRINGEMENT OR FITNESS FOR A PARTICULAR PURPOSE
WITH RESPECT TO THE DOCUMENT. For the avoidance of doubt, Arm makes no representation with respect to, and has
undertaken no analysis to identify or understand the scope and content of, third party patents, copyrights, trade secrets, or other
rights.
This document may include technical inaccuracies or typographical errors.
TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL ARM BE LIABLE FOR ANY DAMAGES,
INCLUDING WITHOUT LIMITATION ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE, OR
CONSEQUENTIAL DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING
OUT OF ANY USE OF THIS DOCUMENT, EVEN IF ARM HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.
This document consists solely of commercial items. You shall be responsible for ensuring that any use, duplication or disclosure of
this document complies fully with any relevant export laws and regulations to assure that this document or any portion thereof is
not exported, directly or indirectly, in violation of such export laws. Use of the word “partner” in reference to Arm’s customers is
not intended to create or refer to any partnership relationship with any other company. Arm may make changes to this document at
any time and without notice.
If any of the provisions contained in these terms conflict with any of the provisions of any click through or signed written
agreement covering this document with Arm, then the click through or signed written agreement prevails over and supersedes the
conflicting provisions of these terms. This document may be translated into other languages for convenience, and you agree that if
there is any conflict between the English version of this document and any translation, the terms of the English version of the
Agreement shall prevail.
The Arm corporate logo and words marked with ® or ™ are registered trademarks or trademarks of Arm Limited (or its
subsidiaries) in the US and/or elsewhere. All rights reserved. Other brands and names mentioned in this document may be the
trademarks of their respective owners. Please follow Arm’s trademark usage guidelines at http://www.arm.com/company/policies/
trademarks.
Copyright © 2018 Arm Limited (or its affiliates). All rights reserved.
Arm Limited. Company 02557590 registered in England.

101308_0000-0.6dev_02_en

Arm® TBSAv8-M Architecture Test

110 Fulbourn Road, Cambridge, England CB1 9NJ.
LES-PRE-20349
Confidentiality Status
This document is Non-Confidential. The right to use, copy and disclose this document may be subject to license restrictions in
accordance with the terms of the agreement entered into by Arm and the party that Arm delivered this document to.
Unrestricted Access is an Arm internal classification.
Product Status
The information in this document is for an Alpha product, that is a product under development.
Web Address
http://www.arm.com

101308_0000-0.6dev_02_en

Contents
Arm® TBSAv8-M Architecture Test Validation
Methodology and User Guide

Preface
About this book ...................................................... ...................................................... 7
Feedback ...................................................................................................................... 9

Chapter 1

Introduction
1.1
1.2
1.3
1.4
1.5
1.6

Chapter 2

Prerequisites for running DPM related tests in TBSA-v8M test suite ...................... 2-19

Architecture test suite
3.1
3.2
3.3
3.4
3.5
3.6

101308_0000-0.6dev_02_en

1-11
1-12
1-13
1-14
1-15
1-17

Porting steps
2.1

Chapter 3

Abbreviations ..................................................... .....................................................
TBSA-v8M test suite ................................................................................................
Components of the test suite ......................................... .........................................
Compliance sign-off process ......................................... .........................................
Getting started .................................................... ....................................................
Feedback, contributions, and support .................................. ..................................

Test layering details ................................................ ................................................
Build flow ........................................................ ........................................................
Test execution flow ..................................................................................................
Test dispatcher .................................................... ....................................................
Test naming conventions ............................................ ............................................
Test status reporting ................................................................................................

3-21
3-22
3-23
3-25
3-27
3-28

Appendix A

Revisions
A.1

101308_0000-0.6dev_02_en

Revisions ................................................... ................................................... Appx-A-30

Preface

This preface introduces the Arm® TBSAv8-M Architecture Test Validation Methodology and User Guide.
It contains the following:
• About this book on page 7.
• Feedback on page 9.

101308_0000-0.6dev_02_en

Preface
About this book

About this book
This book describes the TBSAv8-M Architecture Test Validation Methodology.
Product revision status
The rmpn identifier indicates the revision status of the product described in this book, for example, r1p2,
where:
rm Identifies the major revision of the product, for example, r1.
pn Identifies the minor revision or modification status of the product, for example, p2.
Intended audience
This user guide is written for engineers who are validating an implementation of the Trusted Base
System Architecture Test Suites for Armv8-M.
Using this book
This book is organized into the following chapters:
Chapter 1 Introduction
Read this chapter for an introduction to the features and components of the Trusted Base System
Architecture Test Suites for Armv8-M.
Chapter 2 Porting steps
Read this chapter for information on configuring the test suite.
Chapter 3 Architecture test suite
Read this chapter for information on the tests that are provided with the test suite.
Appendix A Revisions
This appendix describes the technical changes between released issues of this book.
Glossary
The Arm® Glossary is a list of terms used in Arm documentation, together with definitions for those
terms. The Arm Glossary does not contain terms that are industry standard unless the Arm meaning
differs from the generally accepted meaning.
See the Arm® Glossary for more information.
Typographic conventions
italic
Introduces special terminology, denotes cross-references, and citations.
bold
Highlights interface elements, such as menu names. Denotes signal names. Also used for terms
in descriptive lists, where appropriate.
monospace

Denotes text that you can enter at the keyboard, such as commands, file and program names,
and source code.
monospace

Denotes a permitted abbreviation for a command or option. You can enter the underlined text
instead of the full command or option name.
monospace italic

Denotes arguments to monospace text where the argument is to be replaced by a specific value.
monospace bold

Denotes language keywords when used outside example code.
101308_0000-0.6dev_02_en

Preface
About this book

Encloses replaceable terms for assembler syntax where they appear in code or code fragments.
For example:
MRC p15, 0, , , ,
SMALL CAPITALS

Used in body text for a few terms that have specific technical meanings, that are defined in the
Arm® Glossary. For example, IMPLEMENTATION DEFINED, IMPLEMENTATION SPECIFIC, UNKNOWN, and
UNPREDICTABLE.
Timing diagrams
The following figure explains the components used in timing diagrams. Variations, when they occur,
have clear labels. You must not assume any timing information that is not explicit in the diagrams.
Shaded bus and signal areas are undefined, so the bus or signal can assume any value within the shaded
area at that time. The actual level is unimportant and does not affect normal operation.
Clock
HIGH to LOW
Transient
HIGH/LOW to HIGH
Bus stable
Bus to high impedance
Bus change
High impedance to stable bus

Figure 1 Key to timing diagram conventions

Signals
The signal conventions are:
Signal level
The level of an asserted signal depends on whether the signal is active-HIGH or active-LOW.
Asserted means:
• HIGH for active-HIGH signals.
• LOW for active-LOW signals.
Lowercase n
At the start or end of a signal name denotes an active-LOW signal.
Additional reading
This book contains information that is specific to this product. See the following documents for other
relevant information.
Arm publications
• Arm® Platform Security Architecture Trusted Base System Architecture for Armv8-M version
Beta-1 () DEN 0062A.
• Arm®v8-M Architecture Reference Manual (ARM DDI 00553A.b).
Other publications
None.

101308_0000-0.6dev_02_en

Preface
Feedback

Feedback
Feedback on this product
If you have any comments or suggestions about this product, contact your supplier and give:
• The product name.
• The product revision or version.
• An explanation with as much information as you can provide. Include symptoms and diagnostic
procedures if appropriate.
Feedback on content
If you have comments on content then send an e-mail to errata@arm.com. Give:
•
•
•
•

The title Arm TBSAv8-M Architecture Test Validation Methodology and User Guide.
The number 101308_0000-0.6dev_02_en.
If applicable, the page number(s) to which your comments refer.
A concise explanation of your comments.

Arm also welcomes general suggestions for additions and improvements.
Note
Arm tests the PDF only in Adobe Acrobat and Acrobat Reader, and cannot guarantee the quality of the
represented document when used with any other PDF reader.

101308_0000-0.6dev_02_en

Chapter 1
Introduction

Read this chapter for an introduction to the features and components of the Trusted Base System
Architecture Test Suites for Armv8-M.
It contains the following sections:
• 1.1 Abbreviations on page 1-11.
• 1.2 TBSA-v8M test suite on page 1-12.
• 1.3 Components of the test suite on page 1-13.
• 1.4 Compliance sign-off process on page 1-14.
• 1.5 Getting started on page 1-15.
• 1.6 Feedback, contributions, and support on page 1-17.

101308_0000-0.6dev_02_en

1-10

1 Introduction
1.1 Abbreviations

1.1

Abbreviations
This section lists the acronyms that are used in this document.
Table 1-1 Abbreviations and expansions
Abbreviation Expansion

101308_0000-0.6dev_02_en

AES

Advanced Encryption Standard

DPM

Debug Protection Mechanism

I2C

Inter-Integrated Circuit

IDAU

Implementation Defined Attribution Unit

MPC

Memory Protection Controller

MPU

Memory Protection Unit

NSC

Non-secure Callable

NVIC

Nested Vector Interrupt Controller

NVM

Non-Volatile Memory

OTP

One-time Programmable

PAL

Platform Abstraction Layer

Processing Element

PPC

Peripheral Protection Controller

Security Attribution Unit

SPI

Serial Peripheral Interface

TBSA

Trusted Base System Architecture

VAL

Validation Abstraction Layer

1-11

1 Introduction
1.2 TBSA-v8M test suite

1.2

TBSA-v8M test suite
The test suite checks whether an implementation conforms to the behaviors described in the TBSA
specifications.
The TBSA-v8M that is described in the TBSA-v8M specification defines the behavior of an abstract
machine, referred to as a TBSA-v8M system. Implementations compliant with TBSA-v8M architecture
must conform to the described behavior of the TBSA-v8M System.
The test suite includes the following examples:
1. Invariant behaviors that are provided by the TBSA-v8M Architecture Specification. You can use
these examples to verify if these behaviors are interpreted correctly.
2. Areas of the architecture that are fundamental, known pitfalls, and common misinterpretations. The
tests are not exhaustive and implementers are responsible for device verification.
The TBSA-v8M test suite contains basic and assisted architecture tests. The system designers building a
basic implementation of TBSA-v8M architecture must show compliance using the basic architecture test
suites. System designers building an assisted implementation of TBSA-v8M must show compliance
using both the basic and assisted architecture test suites.
The test suites contain self-checking tests. These tests have checks that are embedded within the test
code. Tests are coded in assembly and C.
To facilitate test reporting and management of observing aspects, the TBSA-v8M system must contain at
least one UART for printing the status of tests.
This section contains the following subsection:
• 1.2.1 Scope of the document on page 1-12.

1.2.1

Scope of the document
This document describes the layers of TBSA-v8M test suite and its usage. This document is intended to
solicit feedback from partners so that TBSA-v8M test suite can be used agnostic to various system
implementations.
Since TBSA-v8M test suite is at Alpha stage, only a subset of tests released with this suite are validated
in the Arm internal platform. There are possibilities to have tests where the test code is complete for a
particular scenario but cannot be validated in the Arm internal platform.

101308_0000-0.6dev_02_en

1-12

1 Introduction
1.3 Components of the test suite

1.3

Components of the test suite
The test suite consists of the components that are described in the following table.

Components Description
Suites

The suites are organized to align with the features of the TBSA-v8M architecture. These suites contain self-checking
tests that are written in C language.

Substructure

Test supporting layers consist of a framework and libraries setup as:
• Scripts to build the test suites
• VAL library
• PAL library

Documentation Kit-specific documents.

101308_0000-0.6dev_02_en

1-13

1 Introduction
1.4 Compliance sign-off process

1.4

Compliance sign-off process
More details on the compliance sign-off or certification process and expectations from partner on this
process will be published in the upcoming releases of this document.

101308_0000-0.6dev_02_en

1-14

1 Introduction
1.5 Getting started

1.5

Getting started
This section provides an overview about getting started with the test suite.
This section contains the following subsections:
• 1.5.1 Directory structure on page 1-15.
• 1.5.2 Software, tools, and licensing requirements on page 1-16.
• 1.5.3 Environment requirements on page 1-16.

1.5.1

Directory structure
Validation tests require that the components of the test suite are in a specific hierarchy.
When the test suite release package is downloaded from GitHub, the top-level directory contains the files
that are shown in the following figure.
tbsa-v8m/
docs
Makefile
platform
README.md
tbsa_app
test_pool
tools
val

Figure 1-1 Test suite directory structure

docs
This directory contains the test suite documentation.
platform
This directory contains files to form PAL. PAL is the closest to hardware and is aware of
underlying hardware details. Since this layer interacts with hardware, it is ported or tailored to
specific hardware required for system components present in a platform. This layer is also
responsible for presenting a consistent interface to the validation abstraction layer required for
the tests.
tbsa_app
This directory contains the entry point for TBSA-v8M test suites. It is expected from partner
that the System under test – boot software would give control to the TBSA-v8M test suite
application entry point in Secure privileged mode.
test_pool
This directory contains the test suites. This test suite is a set of C-based directed tests, each of
which verifies the implementation against a test scenario that is described by the TBSA-v8M
specification. These tests are abstracted from the underlying hardware platform by the VAL.
tools
This directory contains subdirectories for the tools and scripts that are used in the test suite.
val
This directory contains subdirectories for the VAL libraries. This layer provides a uniform and
consistent view of the available test infrastructure to the tests in the test pool. The VAL makes
appropriate calls to the PAL to achieve this functionality. This layer is not ported when the
underlying hardware changes.

101308_0000-0.6dev_02_en

1-15

1 Introduction
1.5 Getting started

1.5.2

Software, tools, and licensing requirements
The test suite requires specific versions of software to operate. The following list provides the details of
the platform and tools that are needed for the test suite.
•
•
•

Host Operating System: Ubuntu, Cygwin
Scripting tools: Perl 5.22.1
Other open-source tools: GCC 6.3.1

TBSA-v8M test suite is distributed under Apache v2.0 license.
1.5.3

Environment requirements
The following are the minimum memory requirements for TBSA-v8M test suite to run.
•
•
•
•

64KB of Secure memory and 16KB of Non-secure memory to store VAL or PAL functions and
related data
16KB of Secure Contiguous Memory for secure tests
16KB of Non-secure Contiguous Memory for Non-secure tests
4KB of NSC memory

This memory must be usable for both code execution and data access.
Note
•
•

There is no specific requirement on the number of MPU and SAU regions for TBSA-v8M test suites.
For Non-secure and NSC memory, it is assumed that SAU or IDAU regions are programmed
correctly with Non-secure and Non-secure Callable attributes respectively before getting into
tbsa_entry point.

To learn the details of your hardware environment, the validation tests read the tbsa_tgt.cfg file. Refer
to Chapter 2 Porting steps on page 2-18.

101308_0000-0.6dev_02_en

1-16

1 Introduction
1.6 Feedback, contributions, and support

1.6

Feedback, contributions, and support
For feedback, use the GitHub Issue Tracker that is associated with this repository.
For support, send an e-mail to support-psa-arch-tests@arm.com with the details.
Arm licensees can contact Arm directly through their partner managers. Arm welcomes code
contributions through GitHub pull requests. See GitHub documentation on how to raise pull requests.

101308_0000-0.6dev_02_en

1-17

Chapter 2
Porting steps

Read this chapter for information on configuring the test suite.
It contains the following section:
• 2.1 Prerequisites for running DPM related tests in TBSA-v8M test suite on page 2-19.

101308_0000-0.6dev_02_en

2-18

2 Porting steps
2.1 Prerequisites for running DPM related tests in TBSA-v8M test suite

2.1

Prerequisites for running DPM related tests in TBSA-v8M test suite
Since DPM scenarios in TBSA-v8M involve verifying whether debug access is allowed in a target or not
based on DPM settings, an external debugger is required.
The handshaking and data transfer protocol between the external debugger and Processing Element is
handled by two memory mapped registers named as data and flag register. The description of these
registers is given in the following table.

Figure 2-1 Data and flag registers
Table 2-1 Bit field and description
Bit field

Description

Txfull

This bit is set when CPU writes to Data register. This bit is cleared when debugger reads the data from Data register.

Rxfull

This bit is set when debugger writes to the data register and cleared when CPU reads the Data register

Ready

When this bit is set, debugger is ready to receive commands (Data).

Sequence Type This field indicates debugger to choose appropriate sequence, which the test expects.

Note
•

•

The memory mapped address for these two registers must be chosen in such a way that debug access
to these addresses are allowed even when Invasive Debug is not allowed. The address for these two
registers should be populated in syscomp_tbsa_m/boards//tbsa_tgt.cfg.
A reference program for DS-5 external debugger is available at syscomp_tbsa_m/tools/debug/
debugger_script.py. If you use your specific debugger, then you must port this program to use in
your debugger-specific commands.

101308_0000-0.6dev_02_en

2-19

Chapter 3
Architecture test suite

Read this chapter for information on the tests that are provided with the test suite.
It contains the following sections:
• 3.1 Test layering details on page 3-21.
• 3.2 Build flow on page 3-22.
• 3.3 Test execution flow on page 3-23.
• 3.4 Test dispatcher on page 3-25.
• 3.5 Test naming conventions on page 3-27.
• 3.6 Test status reporting on page 3-28.

101308_0000-0.6dev_02_en

3-20

3 Architecture test suite
3.1 Test layering details

3.1

Test layering details
TBSA-v8M tests are self-checking, portable C-based tests with directed stimulus.
The tests use the layered software-stack approach to enable porting across different test platforms. The
constituents of the layered stack are:
1. Test suite
2. VAL
3. PAL

Figure 3-1 Layered software stack

The following table describes the different layers of the test.
Table 3-1 Test layers and descriptions
Layer

Description

Test suite Collection of targeted tests that validate the compliance of the target system. These tests use interfaces that are provided by
the VAL.
VAL

Contains subdirectories for the VAL libraries. This layer provides a uniform and consistent view of the available test
infrastructure to the tests in the test pool. The VAL makes appropriate calls to the PAL to achieve this functionality. This
layer is not ported when the underlying hardware changes.

PAL

This layer is the closest to hardware and is aware of underlying hardware details. Since it interacts with hardware, it must
be ported or tailored to specific hardware required for system components present in a platform. It is also responsible for
presenting a consistent interface to the validation abstraction layer required for the tests.

101308_0000-0.6dev_02_en

3-21

3 Architecture test suite
3.2 Build flow

3.2

Build flow
Each test file must have a metadata section that describes the high-level details of the test such as Test
ID, test name, and secure specification requirement. The metadata is filled in the form of macros.
As a precompile step, the metadata in each file is extracted, parsed, and saved in a separate file. The
metadata file is used during the package creation phase to fill the tbsa_test_hdr. VAL and PAL files
are not required to have a metadata section.

Figure 3-2 Build flow

Build steps
To compile and build the test images for the complete test suite, use the following command:
make TARGET=

For example,
make TARGET=fvp

Build outputs
The output of the build process is a collection of tests along with metadata of each test packaged
as a single binary file and an ELF file. These files are:
• tbsa_test_combined.bin
• tbsa.elf
Both tbsa_test_combined.bin and tbsa.elf are available under ./out//
The following figure shows the directory structure after building the test ELF images.
out/fvp/
tbsa.asm
tbsa.bin
tbsa.elf
tbsa.hex
tbsa.map
tbsa_pal.a
tbsa_test_combined.bin
tbsa_test_combined.hex
tbsa_val.a

Figure 3-3 TBSA test suite directory structure
101308_0000-0.6dev_02_en

3-22

3 Architecture test suite
3.3 Test execution flow

3.3

Test execution flow
The System Under Test (SUT) boots to an environment that enables the PAL functionality.
At this point, the SUT boot software gives control to the TBSA-v8M test suite application entry point
tbsa_entry that comes from ELF header of tbsa.elf image in Secure privileged mode.

Figure 3-4 Test execution flow

The TBSA-v8M test suite application queries the VAL layer to get the necessary information to run the
tests. This information includes memory maps, interrupt maps, and hardware controller maps.
Due to RAM and flash size constraints, all the tests may not be available at the same time. The
dispatcher in the VAL queries the PAL to load the next test on the completion of the present test. The

101308_0000-0.6dev_02_en

3-23

3 Architecture test suite
3.3 Test execution flow

PAL may optionally communicate with the external world to load the next test. Also, the dispatcher
makes VAL (and in turn PAL) calls to save and report each of the test results.
Each test must present Secure and Non-secure entry points. If a scenario does not warrant either Secure
or Non-secure functionality, then the entry functions will be empty.
To achieve some of the above-mentioned functions, the PAL may optionally make calls that are handled
outside the system under test.
The following are some of the responsibilities that require external support:
• Feed the tests to the design under test.
• Collate and print the test status and messages.
Power ON/OFF the system as required by the test sequence. The environment in which a host test
harness is running is beyond the scope of this document. But, it is envisioned that the SUT is
communicating with the host using Serial port, JTAG, Wi-Fi, USB or any other means that allow for
access to the external world.

101308_0000-0.6dev_02_en

3-24

3 Architecture test suite
3.4 Test dispatcher

3.4

Test dispatcher
Each test must present the following test entry points to the dispatcher.
1. Secure
a. Entry hook
b. Payload
c. Exit hook
2. Non-secure
a. Entry hook
b. Payload
c. Exit hook
To each of the entry points, the dispatcher passes a pointer to a structure containing the function pointers
to all the available VAL functions. The Secure entry points receive the function pointers to the Secure
VAL APIs. The Non-secure entry points receive function points to the Non-secure wrapper functions in
the NSC region. These functions make the appropriate secure VAL function call.
The dispatcher first makes the Secure function calls and on success, calls the Non-secure functions.
The flow of the dispatcher is described in the following steps.
1. Request VAL to load the metadata of the next test into the main memory.
2. Parse the metadata that is associated with the test.
3. Verify that test is compatible with the system under test.
4. Load the test code and data sections to the appropriate locations in the main memory.
5. Call the Secure entry hook function of the test.
6. Call the Secure payload test function.
7. Call the Secure exit hook.
8. Call the Non-secure entry hook function.
9. Call the Non-secure payload function.
10. Call the Non-secure exit hook function.
11. Signal test completion and log test status.
The results from execution of each test are saved to memory. If a display console is not available, the
PAL must make available the test results to the external world through other means.

101308_0000-0.6dev_02_en

3-25

3 Architecture test suite
3.4 Test dispatcher

Figure 3-5 Loading a test from secondary storage

The tbsa.elf is loaded by the bootloader or embedded OS to the Secure memory. The dispatcher within
the tbsa.elf loads each of the Secure test section to Secure memory and Non-secure test section to
Non-secure memory. The addresses of the various sections are predetermined for a given platform as
defined by the user and vary for different targets.

101308_0000-0.6dev_02_en

3-26

3 Architecture test suite
3.5 Test naming conventions

3.5

Test naming conventions
TBSA-v8M tests are named based on the components as defined in the following table.
Table 3-2 Test naming conventions
Component name Base address Test number range
Base

1-19

Boot

21-39

Crypto

41-59

Debug

61-79

EIP

81-99

Interrupts

101-119

Secure RAM

121-139

Peripherals

141-159

Trusted timers

161-179

Version counters

181-199

Each component can have a maximum of 19 tests. Hence the test numbers will be incremented from their
respective base values.
For example, if you see a display as shown below, then for the Secure RAM, the component base value is
200. The test name reports it as 201, which means that it is the first test in the Secure RAM component.
-------------------- Secure RAM Tests -------------------201 : "R180_TBSA_INFRA"

101308_0000-0.6dev_02_en

3-27

3 Architecture test suite
3.6 Test status reporting

3.6

Test status reporting
When the test suite is run on a target platform, each successfully run test of the suite must report either
PASS or SKIP.
The following is a snippet of a successful pass test on the display console.
----------------------- Secure RAM Tests
-----------------------201 : "R180_TBSA_INFRA"
"Secure RAM access from Trusted world only"
# Secure
PASS
# Non Secure
PASS

The following is a snippet of a successful skip test on the display console.
----------------------- Secure RAM Tests
--–--------------------201 : "R180_TBSA_INFRA"
"Secure RAM access from Trusted world only"
# Secure
SKIP
# Non Secure
SKIP

This section contains the following subsection:
• 3.6.1 Debugging of a failing test on page 3-28.
3.6.1

Debugging of a failing test
Since each test is organized with a logical set of self-checking code, if there is a failure then searching
for the relevant self-checking point will be a useful point to start off with debugging.
Consider the below snippet of a failing test on the display console.
----------------------- Trusted Boot Tests
--–--------------------11 : "R020/R090_TBSA_BOOT"
"Trusted boot operation from Trusted and Non-trusted world"
# Secure
Checkpoint C01 : Status = 8C
FAIL
# Non Secure
FAIL

Here are some debugging points to consider.
1. This test is failing for ‘Trusted Boot’ component. Hence the test should be under test_pool/boot/
directory.
2. The test ID is 11 which means first test in ‘Trusted Boot’ component. Hence the test is test_pool/
boot/test_s001 directory.
3. Each test will have a Secure portion and a Non-secure portion. In the above snippet, the failure is
from the Secure portion. Hence it is required to see test_pool/boot/test_s001/secure.c file.
4. Since the failure is shown as ‘Checkpoint C01, the first checkpoint is failing with a status ‘8C’.
5. Status of the failure is mapped with a structure tbsa_status_t that is available at val/include/
val_common.h. In this example, ‘8C’ means that the test is failing for an incorrect value.

101308_0000-0.6dev_02_en

3-28

Appendix A
Revisions

This appendix describes the technical changes between released issues of this book.
It contains the following section:
• A.1 Revisions on page Appx-A-30.

101308_0000-0.6dev_02_en

Appx-A-29

A Revisions
A.1 Revisions

A.1

Revisions
Table A-1 Issue PJDOC-2042731200-3327
Change

Location Affects

This is the first revision of the document. -

All revisions

Table A-2 Differences between Issue PJDOC-2042731200-3327 and Issue 101308-01
Change

Location

Affects

Updated directory structure.

See 1.5.1 Directory structure on page 1-15.

All revisions

Updated porting steps.

See Porting steps to create a new target.

All revisions

Updated test naming conventions. See 3.5 Test naming conventions on page 3-27. All revisions
Table A-3 Differences between Issue 101308-01 and Issue 101308-02
Change

Location

Affects

Updated test naming conventions table. See 3.5 Test naming conventions on page 3-27 All revisions.
Updated PAL APIs.

101308_0000-0.6dev_02_en

See PAL APIs

All revisions.

Appx-A-30

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.7
Linearized                      : Yes
Encryption                      : Standard V4.4 (128-bit)
User Access                     : Print, Copy, Annotate, Fill forms, Extract, Print high-res
Author                          : ARM
Create Date                     : 2018:08:10 14:30:38+05:30
Modify Date                     : 2018:08:10 14:37:47+05:30
Subject                         : This book describes the TBSAv8-M Architecture Test Validation Methodology.
Language                        : EN
XMP Toolkit                     : Adobe XMP Core 5.6-c015 84.159810, 2016/09/10-02:41:30
Format                          : application/pdf
Creator                         : ARM
Description                     : This book describes the TBSAv8-M Architecture Test Validation Methodology.
Title                           : Arm® TBSAv8-M Architecture Test Validation Methodology and User Guide
Creator Tool                    : AH XSL Formatter V6.4 MR2 for Linux64 : 6.4.4.28196 (2017/03/15 08:49JST)
Metadata Date                   : 2018:08:10 14:37:47+05:30
Producer                        : Antenna House PDF Output Library 6.4.993 (Linux64)
Trapped                         : False
Document ID                     : uuid:0c071f32-caac-4a7b-882c-139bb7b34aed
Instance ID                     : uuid:2e69db7f-d473-475d-974e-61b5f28548ac
Page Mode                       : UseOutlines
Page Count                      : 30

EXIF Metadata provided by EXIF.tools

Arm® TBSAv8 M Architecture Validation Methodology And User Guide Arm TBSA V8M Arch

Navigation menu

Versions of this User Manual:

Views

Navigation