This gives callers finer-grained control over the flash. For example,
giving --dfuse-modifiers=force:mass-erase allows a chip-erase rather
than just erasing the sectors which need to be overwritten with the image.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Enable DT support in the dfu-util flasher when the target is a
DfuSe (DFU + ST extensions) device.
Untangling DfuSe-specific options (currently, the default is 'leave',
to immediately start running after the flashing is done) from the
actual address makes this cleaner, and sets up a subsequent patch to
let callers set DfuSe options.
It also lets us fix an unnecessary printline when flashing DfuSe
devices. There's no need to reset those, since the 'leave' modifier
starts execution immediately.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Add the necessary infrastructure to the runner core to support
computing flash addresses based on the devicetree. Specifically, add:
- a new RunnerCaps capability, flash_addr, which lets runners declare
when they support flashing to an arbitrary address
- a common --dt-flash option to all runner command line parsers which
support this capability, which lets users request flash addresses to
be computed from device tree
- a ZephyrBinaryRunner helper method, get_flash_address(), which is
the common code needed to compute a flash address from device
tree (or return a default value if non-DT based flashing is
requested). This relies on the BuildConfiguration parser introduced
in an earlier patch.
Subsequent patches will use this functionality in individual runners.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
The various runners (flash/debug scripts) use environment variables to
take arguments. This is legacy behavior which is not desirable.
Use command line arguments instead.
Note: this leaves more general environment variables with publicly
documented behavior in place for now, for compatibility, e.g.:
ZEPHYR_FLASH_OVER_DFU, OPENSDA_FW, ESP_IDF_PATH, PYOCD_DAPARG
For example, when using dfu-util to flash arduino_101, instead of
setting DFUUTIL_PID, DFUUTIL_ALT, and DFUUTIL_IMG environment
variables, have the script invocation look like this:
python3 .../zephyr_flash_debug.py dfu-util flash \
[common arguments omitted] \
--pid=8087:0aba --alt=x86_app \
--img=.../build/zephyr/zephyr.bin
Make similar changes for other runners (openocd, etc.) and
targets (debug, debugserver).
To implement this in the scripts:
- have the individual scripts/support/runner/some-runner.py files
register their own command line arguments
- teach them to construct instances from arguments, not the
environment
- have zephyr_flash_debug.py request runners to register command
line argument parsers, and handle arguments
In the build system:
- add a new board_runner_args() extension function that board.cmake
files can use to add to the zephyr_flash_debug.py command line
- adjust cmake/flash/CMakeLists.txt to invoke with arguments
- add new helper include files for each runner (like
boards/common/dfu-util.board.cmake, etc.), which add default
options as needed and then add on overrides from
board_runner_args() calls
- update board.cmake files to use the new includes and extension
This implied some tweaking when using openocd to make the CMake string
escaping and unescaping work properly.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
I keep tripping over not being able to use set_ifndef to set a value
to a list, like this:
set_ifndef(VARIABLE value1 value2 value3...)
Allow that to work without changing its existing behavior when called
with one argument.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Some configuration options or device tree nodes affect the way that
runners ought to behave, but there's no good way for them to report
whether they can handle them.
One motivating example is CONFIG_FLASH_LOAD_OFFSET, as influenced by
the zephyr,code-partition chosen node in the DT for architectures
where CONFIG_HAS_FLASH_LOAD_OFFSET=y.
If CONFIG_FLASH_LOAD_OFFSET is nonzero, the 'flash' command ought to
place the kernel at that address offset from the device flash's start
address. Runners don't support this right now, which should be
fixed. However, we don't want to mandate support for this feature,
since not all targets need it.
We need to let runners declare what their capabilities are. Make it so
by adding a RunnerCaps class to the runner core. This currently just
states which commands a runner can handle, but can be generalized to
implement the above use case.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
The Python-based runners have replaced the old shell scripts. Refactor
the build system accordingly:
- FLASH_SCRIPT is now BOARD_FLASH_RUNNER
- DEBUG_SCRIPT is now BOARD_DEBUG_RUNNER
The values, rather than being the names of files, are now the names of
runners in scripts/support/runner. They are still short, descriptive
names like "openocd", "jlink", "em-starterkit", etc.
Adjust the zephyr_flash_debug.py call and runner internals
accordingly. Have each runner class report a name and the commands it
can handle. This lets us move some boilerplate from each do_run()
method into the common run() routine, and enables further improvements
in future patches.
The handles_command() method is temporary, and will be replaced by a
more general mechanism for describing runner capabilities in a
subsequent patch. The initial use case for extending this is to add
device tree awareness to the runners.
To try to avoid user confusion, abort the configuration if an
xxx_SCRIPT is defined.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Have the subclasses implement a do_run() method instead, which run()
delegates to. This will make it possible to handle common
functionality in the superclass before runner-specific methods are
called. It is a prerequisite for tasks like loading the build time
configuration to add device tree awareness.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Any node which needs to generate defines from DTS must have a
"compatible" property, because the corresponding "constraint" is what
extract_dts_includes.py uses to match nodes with YAML files.
There are a few YAML files in the tree that list compatible as
"optional". Fix them.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Of the filesystems under subsys/fs/, only the ELM FAT filesystem needs
the disk layer as others (like NFFS) talk directly to the flash API.
This removes the need to define CONFIG_DISK_ERASE_BLOCK_SIZE and
similar which are used by the disk subsystem but not by NFFS.
Signed-off-by: Michael Hope <mlhx@google.com>
The APPLICATION_BASE variable in the example Kconfig file was copied
in from an (out of tree) application which relied on it during the
Kbuild days, but it's actually not needed by the CMake build system
and should be removed.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
The stub is supposed to be there to bring up a CPU that needs to be
brought up because the platform requires so, but it needs to be as
practically quiet in terms of printing to the serial port as possible.
Thus, disable printing the boot banner by default.
Signed-off-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Some users might want to inherit their already existing Windows
environment variables into the MSYS2 system. This note explains how to
achieve this.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
When node has 'bus' as 'parent' attribute, change base label to
include parent address in label prefix.
Besides, generates a "_BUS_NAME" define which equals parent label.
Signed-Off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Provide dts yaml bindings for 4 sensors supported by disco_l475_iot1
board:
-hts221, lis3mdl, lps22hb and lsm6dsl
Devices are denoted as i2c-devices and, as such, inherits from
i2c-device.yaml
Signed-Off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Provide generic yaml description for i2c-devices such as sensors
New yaml binding category 'parent/child' is added.
It aims at binding two types of related node such as bus master and
bus slave.
In case of i2c-device object, parent property is 'bus' with value 'i2c'.
In the mean time, i2c node gets child property bus. Master and slave bus
values should match.
As such, 'i2c' node is bus master and 'i2c-devices' nodes are bus slaves
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Add tests of the ability to read or write the stack of another thread.
Use semaphores for explicit synchronization of the start and end of the
other thread to ensure that the attempted stack access occurs while the
thread is alive. This ensures that the MMU/MPU has been configured at
least once to allow userspace access to the stack, and that any
removal of access upon thread termination has not yet occurred. This
therefore should exercise changing the MMU/MPU configuration to remove
access to the other thread's stack when switching back to our
thread.
Tested on qemu_x86 (pass) and on frdm_k64f (with and without the ARM
userspace patches; with them, the tests pass; without, they fail as
expected). Also, as with most of the other tests, if you replace
ztest_user_unit_test() with ztest_unit_test(), then the tests fail as
expected.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
The linker was always picking a weak handler over the actual one.
The linker always searches for the first definition of any function
weak or otherwise. When it finds this function it just links and
skips traversing through the full list.
In the context of userspace, we create the _handlers_ for each system
call in the respective file. And these _handlers_ would get linked to
a table defined in syscalls_dispatch.c. If for instance that this
handler is not defined then we link to a default error handler.
In the build procedure we create a library file from the kernel folder.
When creating this library file, we need to make sure that the file
syscalls_dispatch.c is the last to get linked(i.e userspace.c).
Because the table inside syscalls_dispatch.c would need all the
correct _handler_ definitions. If this is not handled then the system
call layer will not function correctly because of the linker feature.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
To avoid configuration surprises, replace
CONFIG_CLOCK_STM32_PLL_SRC_HSI
with
CONFIG_CLOCK_STM32_PLL_SRC_HSI=y
No impact today, but could depend on tools.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Signed-off-by: Steve Brown <sbrown@cortland.com>
---
The updates to BlueZ' meshctl have not been submitted.
I am submitting this PR only for review. It could be committed
after the patches for the meshctl commands are applied.
During cmake migration the load image was not correctly set.
This was causing flash failures.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
When running on jenkins and other automation environment, TERM will
not be defined and thus tput errors out.
Signed-off-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
For a lot of scenarios the isr stack was no longer enough.
Hence increased the stack size.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
As em7d is supported, all configurations of em_starter_kit version 2.3
are supported. Update all the defconfig to version 2.3.
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
MPU version 3 is included in em7d of em_starterkit 2.3.
The differences of MPU version 3 and version 2 are:
* different aux reg interface
* The address alignment requirement is 32 bytes
* supports secure mode
* supports SID (option)
* does not support memory region overlap
This commit adds the support MPU version 3 and also make some changes to
MPU version 2 to have an unified interface.
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
* em7d of em_starterkit 2.3 supports secure mode. add the support
in kconfig and build system.
* change the default configuration of em_starterkit 2.3 to em7d
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
In ARC's SecureShield, a new secure mode (currently only em) is added.
The secure/normal mode is orthogonal to kernel/user mode. The
differences between secure mode and normal mode are following:
* different irq stack frame. so need to change the definition of
_irq_stack_frame, assembly code.
* new aux regs, e.g, secure status(SEC_STAT), secure vector base
(VECT_BASE_S)
* interrupts and exceptions, secure mode has its own vector base;
interrupt can be configured as secure or normal through the
interrupt priority aux reg.
* secure timers. Two secure timers (secure timer 0 and timer 1) are
added.Here, for simplicity and backwards compatibility original
internal timers (timer 0 and timer1) are used as sys clock of zephyr
* on reset, the processor is in secure mode and secure vector base is
used.
Note: the mix of secure and normal mode is not supported, i.e. it's
assumed that the processor is always in secure mode.
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
Add FIRQ option and change the _isr_wrapper. Currently, firq is
enabled by default, but in some arc configuration, firq can be
disabled.
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
This introduces Bluetooth internal API intended to be used for
qualification purposes. Application may register callbacks to get
data that is not exposed by public API.
Signed-off-by: Mariusz Skamra <mariusz.skamra@codecoup.pl>
This chack shall be performed on attribute uuid type, not uuid provided
in Gatt Get Attributes command paramteres.
Signed-off-by: Mariusz Skamra <mariusz.skamra@codecoup.pl>
Those commands will be used for qualification purposes to verify
the functionality of Mesh Health Model.
Signed-off-by: Mariusz Skamra <mariusz.skamra@codecoup.pl>
This event is needed for qualification purposes to verify functionality
of Mesh Network layer.
Signed-off-by: Mariusz Skamra <mariusz.skamra@codecoup.pl>
Marti Bolivar