| # |
| # 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 always remove the configuration file to force it being |
| # re-generated. 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. |
| # |
| # - then we generate the init config -- why? because to filter which |
| # test cases we can run, we need to see if a CONFIG option is |
| # enabled or not. |
| # |
| # - 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. |
| # |
| # 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) First build step to generate the configuration: |
| # |
| # ^build \ |
| # rm -f %(srcdir)s/outdir-%(tchash)s-%(board)s/.config; \ |
| # mkdir -p %(srcdir)s/outdir-%(tchash)s-%(board)s; \ |
| # make -j -C %(srcdir)s/ %(extra_args)s \ |
| # BOARD=%(board)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 |
| |
| |
| # (2) Support for building/running multiple core SOC/platforms (like |
| # Quark SE); each core is called 'a BSP'. |
| # |
| # Some targets have multiple BSPs and need a stub in BSP1 for BSP2 |
| # to work independently, so these first @build rules take care of |
| # that. How we handle this might change in the future. |
| # |
| # The hack for altering the configuration is dirty. Looking for |
| # better ones. |
| |
| # (2.1) For running on Quark SE ARC only, we need to make a stub for |
| # the x86 core to pipe the serial from/to the ARC. It has to |
| # also be deployed, so we add said kernel to @images. |
| # |
| # (a) 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/samples/stub \ |
| # BOARD=arduino_101 \ |
| # 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 |
| # |
| # (b) 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_devboard/.config; \ |
| # make -j -C $ZEPHYR_BASE/samples/stub \ |
| # BOARD=quark_se_devboard \ |
| # O=%(srcdir_abs)s/outdir-%(tchash)s-stub-x86-quark_se_devboard |
| # |
| # @images [ type == "ah" and quark_se_stub == 'yes' and bsp_model == 'arc'] \ |
| # kernel-x86:%(srcdir)s/outdir-%(tchash)s-stub-x86-quark_se_devboard/zephyr.bin |
| # |
| # (c) 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_devboard/.config; \ |
| # make -j -C $ZEPHYR_BASE/samples/stub \ |
| # BOARD=quark_se_devboard \ |
| # O=%(srcdir_abs)s/outdir-%(tchash)s-stub-x86-quark_se_devboard |
| # |
| # @images [ type == "ma" and quark_se_stub == 'yes' and bsp_model == 'arc'] \ |
| # kernel-x86:%(srcdir)s/outdir-%(tchash)s-stub-x86-quark_se_devboard/zephyr.bin |
| # |
| |
| # (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. So we |
| # do the initial config, pluck the CONFIG_ARC_INIT away and |
| # reconfigure before compiling. UGLY, but it works |
| # |
| # @build [ quark_se_stub == 'yes' and bsp_model == 'x86' ] \ |
| # sed -i 's/^CONFIG_ARC_INIT.*//' \ |
| # %(srcdir)s/outdir-%(tchash)s-%(board)s/.config; \ |
| # make -j -C %(srcdir)s/ %(extra_args)s \ |
| # BOARD=%(board)s O=outdir-%(tchash)s-%(board)s \ |
| # olddefconfig |
| |
| # (2.3) 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 CONFIG_ARC_INIT=y >> \ |
| # %(srcdir)s/outdir-%(tchash)s-%(board)s/.config; \ |
| # make -j -C %(srcdir)s %(extra_args)s \ |
| # BOARD=%(board)s O=outdir-%(tchash)s-%(board)s \ |
| # %(extra_args)s olddefconfig |
| |
| # (2.4) Now the basic build and deploy commands that apply to all the |
| # 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 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 fatal fault in fiber |
| # |
| # 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. |