When a debugger is already connected to the JLink debug adapter
nrfjprog.py would incorrectly detect that the snr is '0' and try to
flash a device with that snr.
Also, when there were no boards connected, nrfjprog.py would
incorrectly state that there were multiple boards connected.
This patch improves the error feedback so that a user can more easily
debug why he can't flash his device.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
For readability, swallow exceptions unless --verbose is given on the
command line. Add a printline to direct the user how to ensure that's
set in case more information out of the flash script is desired.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
The system ID core is a simple read-only device that
provides Qsys systems with a unique identifer.
Nios-II processor systems use the system ID core to
verify that an executable program was compiled targeting
the actual hardware image configured in the target FPGA.
Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
Consolidate and standardize error handling throughout
lwm2m_obj_firmware_pull.c. As well as handle previously
unhandled errors returned from transfer_request().
NOTE: in general, unhandled errors will now result in
RESULT_UPDATE_FAILED. Previously, unhandled errors in
transfer_request() would result in RESULT_CONNECTION_LOST
which might or might not be over-written with another
result later.
Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
The CoAP samples use an MBEDTLS config "config-coap.h" which could be
re-used by the LwM2M sample, except that most servers use a larger
maximum content length setting of 1500 bytes.
Let's add a CONFIG to set this for users of the CoAP lib and set the
CONFIG value for the samples to the 256 size currently used.
Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
The build documentation for this board is misleading. It says to "set
JAILHOUSE_QEMU_IMG_FILE", *then* run cmake commands. But setting the
variable must be part of the cmake commands themselves. Fix it.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Currently, LwM2M firmware download only supports coap2http proxy.
Let's add support for coap2coap proxy as well.
This was tested running Californium demo app cf-proxy on the host
machine with the following setting changed in Californum.properties:
MAX_RESOURCE_BODY_SIZE=524288
Add the following to the samples/net/lwm2m_client/prj.conf:
CONFIG_LWM2M_FIRMWARE_UPDATE_PULL_COAP_PROXY_SUPPORT=y
CONFIG_LWM2M_FIRMWARE_UPDATE_PULL_COAP_PROXY_ADDR="coap://[2001:db8::2]:5682"
Build the sample for qemu_x86 as you would normally, but now
you can use a real world coap address to pull firmware using the 5/0/1
resource. The host machine running cf-proxy will pull the remote
resource and then deliver it to the running qemu sample.
Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
- Mention the prj_dtls.conf setting
- Explain setting up security in the Leshan Demo Server web UI.
Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
- Add needed settings for DTLS support to the lwm2m_ctx structure.
- Add initialization of MBEDTLS to the LwM2M lib based on the
user application settings in lwm2m_ctx.
Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
The default net_context remote address is scrambled when using a
connection via DTLS. Instead let's use the dtls context remote.
Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
While looping through possible lwm2m_ctx matches, we're referencing
remote before checking that the context itself is valid.
Also, reduce indentation issues.
Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
Instead of building under the "app" context, let's build the
LwM2M library as a separate static library. This will be helpful
later when adding support for DTLS as w/o this configuration,
the build breaks on MBEDTLS config includes.
Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
Add a debug-only global that prevents commands from running, and just
prints what would have been run.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Allow the user to specify additional options for pyocd-flashtool. This
grants finer-grained control to individual applications, e.g. to
perform a chip erase instead of a sector erase when flashing.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
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>
