NOTE: This applies Zephyr commit 60e97de58 ("scripts: runner:
nrfjprog: Allow specifying serial number of nrfjprog"), which
was merged without going through this tree first.
This allows for scripts using nrfjrog to specify the serial number of
the attached device to use instead of showing a list of available
devices by adding an optional parameter.
Signed-off-by: Jamie McCrae <jamie.mccrae@lairdtech.com>
Signed-off-by: Marti Bolivar <marti@foundries.io>
Add a separate package for bootstrapping West and a Zephyr manifest
repository, and have the setuptools integration install that instead
of the "real" West.
Signed-off-by: Marti Bolivar <marti.f.bolivar@gmail.com>
The setuptools entry_points kwarg can generate platform-specific
scripts to run. These call the entry points with no arguments,
however, so tweak our main() to use sys.argv and its caller to stop
passing it.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
This is necessary to properly configure this as a Python package with
setuptools integration.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
By default, use a sector erase to flash boards with nrfjprog.py.
To allow getting the old behavior, add an --erase flag that works the
exact same way as the corresponding jlink.py argument: if present, a
full flash erase is done before programming. If absent, only a sector
erase is done.
Fixeszephyrproject-rtos/zephyr#6147
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Ensure that CmakeCache.get_list() returns an empty list when the cache
entry is the empty string.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
This is not strictly necessary for flashing and debugging, and is
causing issues in Linux environments where users run "make flash" as
root instead of installing udev rules.
Fixes: #7676
(Though we will need to revisit this when adding commands that run
CMake).
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Though commands like "west flash -h" now have help for generic runner
configuration options, runner-specific context is not printed.
In order to print this information, we would ideally want to know the
currently available runners from a build directory. Otherwise, we
can't print the current cached configuration, and the user will likely
be overwhelmed by a giant list of options etc. available for all the
runners in the package.
However, we can't print that information out without re-doing the
build, which is not safe to do when the user just gives '--help'.
To provide more complete help without causing side effects in the
default help output, add a new -H/--context option, which explicitly
re-runs the build (unless --skip-rebuild was given), parses the cache,
and prints context-sensitive help. This can be combined with the -r
option to restrict help to a particular runner.
Examples:
- Print context for all available flash runners:
west flash -H --build-dir build-frdm_k64f/
- Print context for just one runner:
west flash -H --build-dir build-frdm_k64f/ -r jlink
- Print context for all available debug runners, if current
working directory is a build directory:
west debug -H
If no context is available because there is no CMake cache file, this
command can still be used to obtain generic information about
runners. It emits a warning in this case.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Add the build directory to the central runner configuration.
This is commonly useful information.
The first place we can use it is to eliminate guessing the current
working directory when building objects to parse .config.
It's not necessary to modify the build system for this, so leave the
relevant command line flag among the general options.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Continue better integration of the runner subpackage into west by
moving the common runner configuration options into the command
core. This allows commands like "west flash -h" to display help for
common overrides like --kernel-hex.
Adjustments needed to make this happen are:
- Change the build system to separate common configuration values from
runner-specific options and arguments
- Prepare the runner core by defining a new RunnerConfig class that
represents the common configuration, and accepting that from a new
create() method, which replaces create_from_args().
- Convert all concrete runner classes to use the new style of
argument parsing and initialization.
- Group the command options appropriately for help output readability
There's still a bit of tool-specific stuff in the common
configuration (gdb and openocd configuration in particular); a more
generic way to deal with that will be necessary to better support
things like non-GDB debuggers, but that's out of scope of this patch.
All the runner-specific options are still in the runner packge, which
currently prevents them from being included in "west flash -h" etc.
Fixing that is also out of scope of this patch.
This has the ancillary benefit of getting rid of the legacy 'debug'
argument to ZephyrBinaryRunner, which is no longer appropriate since
verbose debug logging is handled by log.py in west.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Replace all informational messages with calls to log functions.
Cases which must interact via the terminal and standard output are not
modified.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
There are a few issues with the intel_s1000 runner:
- it doesn't attach to the client when running debug (this is
a part of the command's contract specified in core.py)
- it uses hard-coded sleeps when running subprocesses instead of
waiting for them to terminate
- it re-implements pre-existing popen_ignore_int() functionality (in a
way that is not portable to Windows) rather than using it directly
Fix these issues.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Make the flake8 linter happy, spell the board name with the correct
case in the module docstring, and keep the usual camel case naming
convention used for classes.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
This is redundant information. The command is already known from the
top-level west command line. We can just feed it to run without
inserting it on the command line as well, which is safe to do now that
zephyr_flash_debug.py is gone.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
When run without any arguments, the commands work the same way that
their CMake equivalents do. For example, if using the Ninja CMake
generator, these are equivalent:
west flash <----> ninja flash
west debug <----> ninja debug
west debugserver <----> ninja debugserver
Like CMake's build tool mode, you can also run them from any directory
in the system by passing the path to the build directory using
--build-dir (-d):
west flash -d build/my-board
The commands will run the CMake-generated build system, so they keep
dependencies up to date and users don't have to manually compile
binaries between running CMake and using this tool.
The commands also support important use cases that CMake can't:
1) Any arguments not handled by 'west flash' et al. are passed to the
underlying runner. For example, if the runner supports --gdb-port,
the default can be overridden like so:
west debugserver --gdb-port=1234
Command processing by the 'west' command can also be halted using
'--'; anything after that point (even if it's an option recognized
by the west command) will be passed to the runner. Example:
west debug -- --this-option-goes-to-the-debug-runner=foo
2) Any runner supported by the board can be selected at runtime using
the -r (--runner) option. For example, if the board's flash runner
defaults to nrfjprog but jlink is supported as well, it can be
selected with:
west flash -r jlink
3) The runner configuration can be persisted elsewhere, edited
offline, and selected at runtime, using --cmake-cache (-c):
west flash -c /home/me/some/other/CMakeCache.txt
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Add a utility method for getting a runner class given its name. This
will be used in an upcoming patch which adds a command for printing
runner information.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
There is a copy in the west util module; now that runner is a
subpackage of west, just import it from there.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
This is a stepping-stone to adding runner functionality into west
itself.
Since all of the runner tools assume a Zephyr build directory layout,
this doesn't put anything generic into a Zephyr-specific tool.
Make minimal adjustments to zephyr_flash_debug.py to keep existing
build system targets working unmodified.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
This will be used in subsequent patches when adding commands that
interface with the runner package. These need to do things like
ensuring the CMake build is up to date, parsing the cache, etc.
To keep that interface clean, provide this functionality in a separate
module.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
We have agreed to develop a meta-tool named "west", which will be a
swiss-army knife of Zephyr development. It will support use cases like
building, flashing and debugging; bootloader integration; emulator
support; and integration with multiple git repositories.
The basic usage for the tool is similar to git(1):
west [common opts] <command-name> [command opts] [<command args>]
There are common options, such as verbosity control, followed by a
mandatory sub-command. The sub-command then takes its own options and
arguments.
This patch adds the basic framework for this tool, as follows:
- a Python 3 package named 'west'. There is no PyPI
integration for now; the tool will be improving quickly, so we need
to keep users up to date by having it in tree.
- an main entry point, main.py, and a package-level shim, __main__.py
- a cmd subpackage, which defines the abstract base class for commands
- logging (log.py)
- catch-all utilities (util.py)
Windows and Unix launchers so users can type "west" to run the tool
after sourcing the appropriate zephyr-env script for their
environment are in the Zephyr tree.
Subsequent patches will start to add individual commands.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Jamie McCrae