Loading...
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 | #
# This file specifies defaults so the testcase running system knows
# how to build Zephyr apps.
#
# It looks all like comments so that it can also put this stuff inside
# Makefiles, shell scripts, python, C, etc...
#
# Things like:
#
## ^COMMAND ARGUMENTS
## @COMMAND ARGUMENTS
#
# are what the parser looks for. ^COMMAND means that if it fails or
# block, the list of COMMANDs will not continue being executed, @
# means the next commands still will be executed. Note the ## is so
# that the parser doesn't interpret it as a command, as we are
# documenting it.
# Variables
# ---------
#
# Every %(VARIABLE)s you are going to use or maybe override has to be
# defined; otherwise it'll throw a KeyError exception on you.
#
# Some are pre-filled by the system (see below), but others are
# user-defined and some test cases make use of it, so we define a
# default value (empty) here:
#
# @var extra_args
# Building
# --------
#
# - We need to put the output of the compilation on a directory
# specific to the target and testcase we are building for because:
#
# - two targets, although the same hardware, might have differences
# that could be or not specified in the target's tags.
#
# - multiple paralallel builds for the same testcase PATH with
# different testcase names (especially those coming from
# testcase.ini) files can collide with each other.
#
# - HACK: ARCH is specified, when it should not be needed to, because
# of current limitations of the Zephyr build system on resolving
# ARCH from the BOARD specification. This is an historical carry
# over that eventually should be cleared
# (https://jira.zephyrproject.org/browse/ZEP-690 and
# https://jira.zephyrproject.org/browse/ZEP-754).
#
# Thus is the `%(tchash)s` substitution, which is a unique hash
# for a combination of the testcase name, the target and the
# bsp_model.
# (1) Remove the existing config file
#
# Why? because otherwise, in some cases, 'silentoldconfig' tries
# to update it with input from the user and fails. When it is not
# needed. So before we start mucking with it, remove it.
#
# ^build \
# mkdir -p %(srcdir)s/outdir-%(tchash)s-%(board)s; \
# rm -f %(srcdir)s/outdir-%(tchash)s-%(board)s/.config
# (2) prepare the configuration for Quark SE / ARC BSPs
#
# (2.1) If we are running both cores at the same time, make sure
# ARC_INIT is set
#
# ^build [ quark_se_stub == 'yes' and bsp_model == 'x86+arc' ] \
# echo "# Generated by Zephyr's TCF defaults.tc" > %(srcdir)s/outdir-%(tchash)s-%(board)s/tcf_2.1.conf; \
# echo 'CONFIG_ARC_INIT=y' >> %(srcdir)s/outdir-%(tchash)s-%(board)s/tcf_2.1.conf
# (2.2) On Quark SE, when running the x86 core only we need to make
# sure the kernel doesn't wait for the ARC to initialize.
#
# @build [ quark_se_stub == 'yes' and bsp_model == 'x86' ] \
# echo "# Generated by Zephyr's TCF defaults.tc" > %(srcdir)s/outdir-%(tchash)s-%(board)s/tcf_2.2.conf; \
# echo 'CONFIG_ARC_INIT=n' >> %(srcdir)s/outdir-%(tchash)s-%(board)s/tcf_2.2.conf
# (2.3) To run only in the ARC core in certain Quark SE platforms, we need a
# stub in the x86 core to start the ARC CPU.
#
# It has to also be deployed, so we add said kernel to @images.
#
# (2.3.1) Arduino 101
#
# @build [ type == "arduino101" and quark_se_stub == 'yes' and bsp_model == 'arc' ] \
# rm -f %(srcdir_abs)s/outdir-%(tchash)s-stub-x86-arduino_101/.config; \
# make -j -C $ZEPHYR_BASE/tests/booting/stub \
# BOARD=arduino_101 ARCH=x86 \
# O=%(srcdir_abs)s/outdir-%(tchash)s-stub-x86-arduino_101
#
# @images [ type == "arduino101" and quark_se_stub == 'yes' and bsp_model == 'arc'] \
# kernel-x86:%(srcdir)s/outdir-%(tchash)s-stub-x86-arduino_101/zephyr.bin
#
# (2.3.2) For Quark SE Devboard v1
#
# @build [ type == "ah" and quark_se_stub == 'yes' and bsp_model == 'arc' ] \
# rm -f %(srcdir_abs)s/outdir-%(tchash)s-stub-x86-quark_se_c1000_devboard/.config; \
# make -j -C $ZEPHYR_BASE/tests/booting/stub \
# BOARD=quark_se_c1000_devboard \
# O=%(srcdir_abs)s/outdir-%(tchash)s-stub-x86-quark_se_c1000_devboard
#
# @images [ type == "ah" and quark_se_stub == 'yes' and bsp_model == 'arc'] \
# kernel-x86:%(srcdir)s/outdir-%(tchash)s-stub-x86-quark_se_c1000_devboard/zephyr.bin
#
# (2.3.3) For Quark SE Devboard
#
# @build [ type == "ma" and quark_se_stub == 'yes' and bsp_model == 'arc' ] \
# rm -f %(srcdir_abs)s/outdir-%(tchash)s-stub-x86-quark_se_c1000_devboard/.config; \
# make -j -C $ZEPHYR_BASE/tests/booting/stub \
# BOARD=quark_se_c1000_devboard \
# O=%(srcdir_abs)s/outdir-%(tchash)s-stub-x86-quark_se_c1000_devboard
#
# @images [ type == "ma" and quark_se_stub == 'yes' and bsp_model == 'arc'] \
# kernel-x86:%(srcdir)s/outdir-%(tchash)s-stub-x86-quark_se_c1000_devboard/zephyr.bin
#
# (2.3.4) When running the ARC in Quark SE, we redirect the output to the
# UART_1 (the same as the x86) to simplify the test setup (no
# need to connect multiple console cables)
#
# However, this makes it impossible to run independent test cases
# at the same time (BSP model x86+arc) because they'd interfere
# with each other.
#
# ^build [ quark_se_stub == 'yes' and bsp == 'arc' ] \
# echo "# Generated by Zephyr's TCF defaults.tc" > %(srcdir)s/outdir-%(tchash)s-%(board)s/tcf_2.3.4.conf; \
# echo 'CONFIG_UART_CONSOLE_ON_DEV_NAME="UART_1"' >> %(srcdir)s/outdir-%(tchash)s-%(board)s/tcf_2.3.4.conf
#
# (2.3.5) Quark SE: run test cases on x86 or ARC modes by default
#
# This applies to test cases that are designed to run only in
# one core, as Quark SE will share one serial port in our test
# setup and the outputs will conflict and be a mess.
#
# Test cases that need to run in both cores (BSP MODEl
# x86+arc) can still request it by tagging '@targets
# bsp_model:x86\+arc'
#
# @targets [ quark_se_stub == 'yes' ] bsp_model:^(x86|arc)$
# (3) Generate the initial configuration
#
# Because to filter which test cases we can run, we need to see if
# a CONFIG option is enabled or not.
#
# ^build \
# make -j -C %(srcdir)s/ %(extra_args)s \
# BOARD=%(board)s ARCH=%(bsp)s O=outdir-%(tchash)s-%(board)s \
# initconfig
#
# Once we have the configuration generated, for Sanity Check test
# cases (and others) evaluate if we have to run or not based on
# configuration values. This is done by a Python function
# (tcfl.tc_tci.action_eval_skip). This looks at CONFIG_ options
# and decides if we are to skip for any reason.
#
# ^build @tcfl.tc_tci.action_eval_skip %(srcdir)s/outdir-%(tchash)s-%(board)s
# (4) General build and deploy commands that apply to all platforms
#
# Note: we pass a RUNID that is a compositon of the RunID passed
# with '-i' to 'tcf run' (if passed) TCHASH (which is
# unique hash of the target and testcase name) -- this
# ensures that succesive test cases ran in the same target
# will have a different TC_RUNID. We will in
# tests/.tcdefaults (when using TC_PRINT_RUNID /
# TC_END_REPORT) to verify that the right image has been
# deployed to the target.
#
# @build \
# make -j -C %(srcdir)s %(extra_args)s \
# KCPPFLAGS=-DTC_RUNID=%(runid)s:%(tchash)s \
# BOARD=%(board)s ARCH=%(bsp)s O=outdir-%(tchash)s-%(board)s
#
# And deploy the kernel we just built
#
# @images kernel-%(bsp)s:%(srcdir)s/outdir-%(tchash)s-%(board)s/%(kernelname)s
# Cleaning up
# -----------
#
# This is only invoked when you give `--clean` or `-L` to `tcf run`
#
# @clean rm -rf %(srcdir)s/outdir-%(tchash)s-*
# Evaluation of the test case
# ---------------------------
#
# These are the steps performed to evaluate a test case / sample for
# success in execution. In here we only list the general ones that
# apply to all of them, but each testcase will have it's specific
# ones.
#
# (1) In general, before evaluating, reset/power-cycle/resume the
# target.
#
# `one-shot` means only once if we are running multiple BSPs and fail
# inmediately if it doesn't work):
#
# ^eval [ type:"(?!^emsk.*)" ] target-reset one-shot
#
# EMSKs get their firmware loaded into RAM; if we do a full reset,
# it is wiped, so we just do a raw reset (which means a CPU reset
# in this case) and resume
#
# ^eval [ type:"^emsk.*" ] debug-reset-halt one-shot
# ^eval [ type:"^emsk.*" ] debug-resume one-shot
#
# (2) Fail inmmediately (^) if we find these messages, that's bad
# stuff happening in the kernel.
#
# ^eval console-rx %(console)s::fail USAGE FAULT
# ^eval console-rx %(console)s::fail [Ff]atal fault in
# ^eval console-rx %(console)s::fail Fatal essential task error
# ^eval console-rx %(console)s::fail Fatal task error!
#
# For testcases under tests/, the .tcdefaults in there adds more steps
# to verify; test cases are picked up based on their
# testcase.ini. Each test case is then free to add more, if
# needed. Note than in samples, most of that information is going to
# be in .tc files.
|