- Pressing 'c' ('n' was taken) toggles a mode where the names of all
symbols are shown before their prompts. This saves going into the
help display when you just want the name.
- The name of the symbol/choice now appears in the main text of the
help dialog rather than in the title, where it might be hard to
spot, as pointed out by Carles Cufi.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Unquoted string defaults work through a quirk of Kconfig (undefined
symbols get their name as their string value), but look confusing. It's
done inconsistently now too.
Suggested by Kumar Gala.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Correctly process multiple include files given to the
!include command of the YAML loader.
The fix only targets the sequential definition of include files.
Fixes#7067
Signed-off-by: Bobby Noelte <b0661n0e17e@gmail.com>
For DWARF v2, DW_AT_data_member_location is encoded as a set of operations. The member_offset is in that case a list that starts with an operation (typically DW_OP_plus_uconst), so member_offset[0] is not the offset.
This solves the kernel/poll test (issue #7885)
Allow check-compliance.py to be run from any path with a valid Git tree,
removing the unnecessary and artificial limitation imposed in the case
of gitlint.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
- Show the value of each symbol in the jump-to dialog.
- Search names and prompts separately in the jump-to dialog.
Previously, '_BAR$' wouldn't match FOO_BAR if it had a prompt,
because '_BAR$' was matched against the string 'FOO_BAR "prompt"'.
- Show the working directory in save/load dialog boxes. Paths will be
relative to it, and Carles Cufi pointed out that it might not be
obvious.
Also allow ~ to be used to refer to the home directory.
- Implement scroll offset for edit boxes. This makes it clearer when
they're scrolled horizontally.
Piggyback an update of Kconfiglib to the latest version (no functional
changes).
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
This section got added in commit 470349c25a ("Bluetooth: settings:
Add support for per-submodule handlers"), but sanitycheck didn't know
about it and was whining.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
On some arches like ARC, the member location tag is a list with
the offset and then the member size. We just need the offset.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Make all menu paths ("(top menu) -> menu -> submenu -> ...") exclude
implicit submenus, which are shown indented in the menuconfig interface
and are created when items depend on the symbol before them.
Previously, implicit submenus were excluded in the menu path at the top
of the menuconfig interface, but were included in the menuconfig symbol
information dialog and in the docs generated by genrest.py.
This makes it consistent, and un-spams the documentation for some
symbols a bit.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Ninja and GNU make don't play well with each other. Both try to start
enough processes to keep the system's CPUs busy, resulting in an
O(N^2) system load in the number of processors.
Long term, Ninja seems likely to support the GNU make jobserver
mechanism for sharing access to parallelism. But for now we can get
90% of the way there with a simple hack: just run ninja in serial mode
with -j1. Sanitycheck when run in non-trivial circumstances has
PLENTY of parallelism just from the number of test cases.
One interesting note is that even with -j1, system loads under ninja
are rather higher. That may be because of significant work done in
the (serial) makefiles that dilutes the parallelism of the eventual
build, or possibly because ninja itself is multithreaded in its setup
code. So I tweaked the number of jobs down to keep the load roughly
where it is with make.
With this change, I see no difference in behavior or system load, and a
~24% improvement in runtime.
Signed-off-by: Andy Ross <andrew.j.ross@intel.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>
Leading/trailing whitespace in prompts requires ugly workarounds in
genrest.py, as e.g. *prompt * is invalid RST. strip() all prompts in
Kconfiglib and get rid of the genrest.py workarounds. Add a warning too.
The Kconfiglib update has some unrelated cleanups and fixes (that won't
affect Zephyr).
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
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>
Since, by design, the west 'flash', 'debug', and 'debugserver'
commands operate the same way as the Makefile targets when given no
arguments, so just delegate to west from cmake/flash/CMakeLists.txt
instead of invoking zephyr_flash_debug.py by hand.
Removing the old script is the first step towards being able to clean
up the command line argument handling in the runner package, which was
always kind of a hack and can be improved now that runner is part of a
larger tool.
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', in scripts/meta. 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.
Subsequent patches will start to add individual commands.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
.config files can now be loaded from within the menuconfig interface.
Show-all mode is turned on if the selected menu entry becomes invisible.
Unrelated fix: The menu path at the top of the display no longer
includes implicit (indentation-based) submenus, which makes it a bit
less spammy and confusing.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
This commit mirrors 0f1229bd68866 ("doc: genrest: Show properties on the
correct symbol definition"), for the menuconfig symbol information
display.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
This commit does some major surgery to Kconfiglib so that properties
(defaults, selects, etc.) can be shown on the menu node that actually
has the propetrty for symbols and choices defined in multiple locations.
This will be used to improve the output of genrest.py and the symbol
information display in the menuconfig.
The parsing code is a bit simpler now too as a side effect.
Commit message from Kconfiglib (63a44186137e2)
==============================================
This allows accurate documentation to be generated for symbols and
choices defined in multiple locations. There are now MenuNode.defaults,
MenuNode.selects, etc., lists that mirror the corresponding
Symbol/Choice lists.
Symbol/Choice.__str__() now correctly show property locations as well,
by simply concatenating the strings returned by MenuNode.__str__() for
each node.
_parse_properties() was modified to add all properties directly to the
menu node instead of adding them to the contained symbol or choice. The
properties are then copied up to symbols and choices in
_finalize_tree(). Dependency propagation is handled at the same time.
As a side effect, this cleans up the code a bit and de-bloats
_parse_properties().
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
This commit gets rid of the 'option env="ENV_VAR"' bounce symbols.
"$FOO" now expands directly to the value of the environment variable
FOO, instead of to the value of the Kconfig symbol FOO.
This change is likely to soon appear in the C tools as well. Those
'option env' symbols always seemed kinda pointless, and have broken
dependency handling due to forcing symbol evaluation during parsing,
before all the symbols have even been seen.
Compatibility with the C tools could be retained by naming all
'option env' symbols the same as the environment variable they
reference.
This commit also updated the Zephyr documentation to explain the new
behavior. It's relevant for $ZEPHYR_BASE and out-of-tree Kconfig
extensions.
Commit message from Kconfiglib (cbf32e29a130d)
==============================================
Make "$FOO" directly reference the environment variable $FOO in e.g.
'source' statements, instead of the symbol FOO. Use os.path.expandvars()
to expand strings (which preserves "$FOO" as-is if no environment
variable FOO exists).
This gets rid of the 'option env' "bounce" symbols, which are mostly
just spam and are buggy in the C tools (dependencies aren't always
respected, due to parsing and evaluation getting mixed up). The same
change will probably appear soon in the C tools as well.
Keep accepting 'option env' to preserve some backwards compatibility,
but ignore it when expanding strings. For compatibility with the C
tools, bounce symbols will need to be named the same as the environment
variables they reference (which is the case for the Linux kernel).
This is a compatibility break, so the major version will be bumped to 6
at the next release.
The main motivation for adding this now is to allow recording properties
on each MenuNode in a clean way. 'option env' symbols interact badly
with delayed dependency propagation.
Side note: I have a feeling that recording environment variable values
might be redundant to trigger rebuilds if sync_deps() is run at each
compile. It should detect all changes to symbol values due to
environment variables changing value.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
k_poll is now accessible from user mode. A memory allocation takes place
from the caller's resource pool to copy the provided poll_events
array; this can be large enough to make allocating it on the stack
not preferable.
k_poll_signal are now proper kernel objects. Two APIs have been added,
one to reset the signaled state and one to check the current signaled
state and result value.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
The various macros to do checks in system call handlers all
implictly would generate a kernel oops if a check failed.
This is undesirable for a few reasons:
* System call handlers that acquire resources in the handler
have no good recourse for cleanup if a check fails.
* In some cases we may want to propagate a return value back
to the caller instead of just killing the calling thread,
even though the base API doesn't do these checks.
These macros now all return a value, if nonzero is returned
the check failed. K_OOPS() now wraps these calls to generate
a kernel oops.
At the moment, the policy for all APIs has not changed. They
still all oops upon a failed check/
The macros now use the Z_ notation for private APIs.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
User mode may now use queue objects. Instead of embedding the kernel's
linked list information directly in the data item, a container struct
is allocated from the caller's resource pool which is then added to
the queue. The new sflist type is now used to store a flag indicating
whether a data item needs to be freed when removed from the queue.
FIFO/LIFOs are derived from k_queues and have had allocator functions
added.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This used to be done by hand but can easily be generated like
we do other switch statements based on object type.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
If a variable is declared extern first, the name and type
information is stored in a special DW_DIE_variable which
is then referenced by the actual instances via the
tag DW_AT_specification.
We now place extern variable instances in an extern environment
and use this data to fetch the name/type of the instances,
which do not have it (which is why they were being skipped).
As it turns out, the gross hack for the system workqueue was
due to this problem because of the extern declaration in
kernel.h.
Fixes: #6992
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This commit gets the following incremental search improvements in from
upstream:
- 1d3db5de9b8c2 ("menuconfig: Add search with multiple search
strings")
This makes a search string like 'foo bar' match all symbol names
that match both 'foo' and 'bar' (which can be regexes), regardless
of the order in which they appear in the match. This is faster and
more flexible than having to type a bunch of '.*'.
- 9bf8fc6e6907e ("menuconfig: Add prompts to incremental search")
This makes the incremental searcher search prompt strings as well as
symbol names.
The prompt is now displayed next to the symbol name in the list of
matches as well.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
The horizontal scroll (hscroll) wasn't initialized properly when the
initial (prefilled) contents of an edit box was longer than the edit box
itself (e.g. when saving with a long path in KCONFIG_CONFIG). Things
snapped back into place once a key was pressed.
Properly initialize hscroll to fix the initial rendering.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
'cell_string' yaml attribute has been introduced in order to
help enforcement of specific string during defines generation.
This adds complexity in understanding script behavior as a black
box and create additional dependency which is not strictly required.
For node specific generation functions (pinctrl and interrupts),
this could be replaced directly by an hardcoded version
(as everyone used the same 'cell_string' anyway).
For extract_cells functions, string could be replaced by extracted
property name. As a consequence, we're now able to generate defines
for properties refering to these controllers via phandle.
For instance, in following node
spbtle-rf@0 {
compatible = "st,spbtle-rf";
reg = <0>;
reset-gpios = <&gpioa 8 0>;
};
We'll be able to generate:
#define ST_STM32_SPI_...LE_RF_0_RESET_GPIOS_CONTROLLER "GPIOA"
#define ST_STM32_SPI_...PBTLE_RF_0_RESET_GPIOS_FLAGS_0 0
#define ST_STM32_SPI_..._SPBTLE_RF_0_RESET_GPIOS_PIN_0 8
Only impact for this whole change is for NXP clocks which were the
only ones using 'cell_string' attribute with a value different than
the default one.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
extract_controller only handle the first phandle in a cell property.
However we could easily have something like this where the phandles
vary:
gpios = <&gpiod 13 GPIO_INT_ACTIVE_LOW
&gpioc 14 GPIO_INT_ACTIVE_LOW>;
So we need to walk the property list for each phandle and produce a
define associated with it.
Also, if alias to the node is defined, indexed alias define
is generated for every indexed controller define:
#define GPIO_LEDS_0_GPIO_CONTROLLER_0 "GPIOA"
#define GPIO_LEDS_0_GPIO_CONTROLLER_1 "GPIOB"
#define LED1_GPIO_CONTROLLER_0 GPIO_LEDS_0_GPIO_CONTROLLER_0
#define LED1_GPIO_CONTROLLER_1 GPIO_LEDS_0_GPIO_CONTROLLER_1
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
If we had something like:
gpios = <&gpiod 13 GPIO_INT_ACTIVE_LOW
&gpiod 14 GPIO_INT_ACTIVE_LOW>;
The script blows up in extract_cells. While extract_cells attempted to
handle more than a single item in such a list, it didn't manipulate the
prop list for the recursive calls properly.
Since we pop off items from the prop list as we use them we can easily
pass the prop list to the rescurive call to fix things.
Besides, if alias is defined for the node, indexed aliases defines are
generated:
#define GPIO_LEDS_0_GPIO_FLAGS_0 4
#define GPIO_LEDS_0_GPIO_FLAGS_1 0
#define GPIO_LEDS_0_GPIO_PIN_0 5
#define GPIO_LEDS_0_GPIO_PIN_1 6
#define LED1_GPIO_FLAGS_0 GPIO_LEDS_0_GPIO_FLAGS_0
#define LED1_GPIO_FLAGS_1 GPIO_LEDS_0_GPIO_FLAGS_1
#define LED1_GPIO_PIN_0 GPIO_LEDS_0_GPIO_PIN_0
#define LED1_GPIO_PIN_1 GPIO_LEDS_0_GPIO_PIN_1
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Indexed defines were systematically generated even when there
was only one element to generate.
So we ended up generated a lot of _0 defines.
Then we needed to generate aliases to these _0 indexed defines,
in order to get useful defines.
For instance:
#define GPIO_LEDS_0_GPIO_FLAGS_0 4
#define GPIO_LEDS_0_GPIO_PIN_0 5
#define GPIO_LEDS_0_GPIO_FLAGS GPIO_LEDS_0_GPIO_FLAGS_0
#define GPIO_LEDS_0_GPIO_PIN GPIO_LEDS_0_GPIO_PIN_0
This commit allows to generate _0 indexed define only if a
property has more than one elements to define.
Aliases generation to _0 indexed defines are also removed.
Note: IRQ are left untouched since this is frequent to handle
multiple IRQs in a driver
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Some functions were using y_key and y_val as argument. This was not
quite easy to read. Rename argument into more informative versions.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
