The production version of the nRF54H20 SoC is now available, so remove
the initial Engineering B (EngB) preview version.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
On nRF54H and nRF92, booting certain cores requires programming a UICR,
which is normally generated using nrf-regtool. This should be considered
an optional dependency, because we do not wish to force non-Nordic users
to install it just to work with Zephyr, or just for build-only tests.
When nrf-regtool is not installed, a CMake warning will be displayed,
but people ignore warnings all the time. As the last line of defense,
check for missing UICR in the nrfutil flash runner, to prevent our users
from unintentionally programming unbootable firmware. Show a fatal error
specifically if CONFIG_NRF_REGTOOL_GENERATE_UICR=y, yet no UICR exists.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
With the recent introduction of the SUIT manifest starter binary blob,
it is now possible to use it with the nRF54H20 during the flashing
procedure in order to provide a valid SUIT manifest to the system.
This PR introduces the code that handles programming the SUIT manifest
starter, as well as a new --suit-manifest-starter command-line option.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Provide a mechanism to propagate useful arguments from one runner to the
next. The primary use case for this is to propagate a JLink serial
number, so that if it is queried from the terminal the user only needs
to make the choice once.
Implements #76077.
Signed-off-by: Jordan Yates <jordan@embeint.com>
It is safer to base the SUIT artifacts path on the path of the
configuration file than the HEX file that is being flashed.
The latter may be overriden by several scripts that merge/transform the
final firmware image.
Signed-off-by: Tomasz Chyrowicz <tomasz.chyrowicz@nordicsemi.no>
In order for the --recover option to work properly on the nRF54H20, it
requires executing it for both cores, the radio and the application one.
Extend the recover_target() function so that it does so for both 53 and
54H20.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Handle MPI and root manifest for radio core separately from the main
build system logic.
Signed-off-by: Tomasz Chyrowicz <tomasz.chyrowicz@nordicsemi.no>
Make the generated json file match the contents generated with:
* nrfutil device erase --uicr --core Application --x-operation-id 1
--x-family nrf54h --x-append-batch batch.json
* nrfutil device program --firmware uicr_merged.hex
--options chip_erase_mode=ERASE_NONE,verify=VERIFY_READ
--core Application --x-operation-id 2 --x-family nrf54h
--x-append-batch batch.json
* nrfutil device reset --reset-kind RESET_PIN --x-operation-id 3
--x-append-batch batch.json
The erase options are supposed to be placed under "option" subkey.
Without the "option" subkey, nrfutil defaulted to ERASE_ALL.
Remove the firmware file format field because it is auto detected by
nrfutil when executing the batch script.
Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
The flasher was unconditionally cleaning the UICR area, even when the
application didn't have a new configuration generated. This can happen,
when CONFIG_NRF_REGTOOL_GENERATE_UICR=n. In such case, keep the old UICR
configuration on the device.
A real scenario where we should set CONFIG_NRF_REGTOOL_GENERATE_UICR=n
is when building multiple firmware images that are meant to run one
domain. The primary application build generates the UICR configuration
and secondary images don't. Before this change, the flashing process of
the primary application would write new UICR configuration, but the
flashing process of secondary images would erase it.
Signed-off-by: Rafał Kuźnia <rafal.kuznia@nordicsemi.no>
nRF54H can only be flashed using nrfutil now, so some workaround present
in the nrf_common module are no longer needed, e.g. UICR erasing.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Add basic support to flash application and/or radio core for nRF54H
series. Note that features like merged hexes present in nRF53 series is
not supported.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
uicr_ranges dictionary entries did not contain the `_FAMILY` suffix, now
used by self.family variable, resulting in an always false check.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
The network core needs to be recovered first due to the fact that
recovering it erases both the network and application cores' flash
memory. This means that the little flash image that is programmed during
the recover operation would be lost for the app core if we inverted the
order.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Some of the runners in the tree have been adding their own,
class-specific versions of a switch to instruct the runner to reset or
not the device after flashing.
In order to better support multi-image builds that require more than one
flash operation, introduce a new --reset,--no-reset command-line
parameter that is part of the RunnerCaps so taht this functionality can
be accessed in a standardized manner.
Implementations for the new parameter are provided for the runner
classes that were already configurable in this regard.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
The now legacy --nrf-family parameter takes the "raw" family name as
nrfjprog accepts it. But now we use an intermediate representation with
{FAMILY}_FAMILY as the format, so covert to it as required.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
In order to better support the ability of the upcoming nrfutil runner to
defer all operations and execute them all at once, defer flushing right
until the end, when everything has been queued up (recover, program and
reset) instead of forcing execution at the program stage.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Standardize to nrfutil error codes instead of nrfjprog ones. This is
because nrfutil has a wider range of functionality and will eventually
be the default runner for all nRF devices. It is also consistent with
the internal operation representation, which is now using the nrfutil
format already.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
The QSPI erase switch is not part of the "firmware" dict, but rather
placed in the overall operation dict.
Fixes#55625.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Generalize the logic that was previously in nrfjprog.py into a new
nrf_common.py, which can then use specific tool subclasses, one of which
is nrfjprog.py, to implement the actual tool invocation.
This commit lays down the groundwork for the addition of a new backend
for nRF boards, the new nrfutil tool from Nordic. Both nrfjprog and
nrfutil will coexist in the immediate future, but nrfutil is expected to
be the sole tool for everything nRF in due time. This is why the internal
representation of the operations is based in JSON and is using the exact
format that nrfutil expects when using the 'execute-batch' option, that
takes a JSON file with an array of operations to be executed.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
This is a partial revert of commit
2cee5ff519
("scripts: west_commands: runners: remove deprecated options").
I remarked at the time that the removal of the older way of writing
things from the runners themselves seemed gratuitous since they are
easy to continue to support indefinitely and people may have been used
to the old way of doing things. It didn't seem worth the fight to push
for a revert at the time, though.
Since then I've run into real problems that their removal has caused
in the wild and I am convinced that this part of that patch was wrong.
Restore the original, undeprecated forms of these options, but make it
clear in the command line help that they're just obsolete alternative
spellings at this point.
Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
The --snr (nrfjprog) --id (jlink) and --board-id (pyocd) options were
deprecated a long time ago in favor of --dev-id. It is time to remove
them.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Currently, it is not possible to use a normal flash command to flash two
hex files that contain data in the UICR region, even though these
data don't conflict with each other.
However, that is not a technical limitation of the device, but of the
nrfjprog runner as it fails as soon as the hex file contained UICR data
and there was no --force/--erase/--recover used.
That approach was used in the past as program operation was used
without --verify, but as this option was added a while ago it is an
unnecessary limitation.
If the UICR wasn't erased before programming, the verify of the program
operation will now fail, so giving the user a warning in this case that
the hex files contain data in the UICR will still give the user a hint
of what might have caused the failing verify.
Additionally, it enables partial programming of the UICR without the
use of the --force option.
Signed-off-by: Markus Swarowsky <markus.swarowsky@nordicsemi.no>
The --tool-opt runner option is the recommended practice for allowing
runners to take additional arguments that are passed on to the
underlying tool. It exists because we don't want to add one runner
option for every single tool option that users might want to tweak --
that would be a nightmare.
Enough runners are using this option that it's time to promote it to a
common runner capability with consistent behavior, the same way we did
for the --dev-id option in the past. This removes boilerplate from
individual runner files and ensures consistent argument handling for
this option when it is supported.
Since --tool-opt is a bit long to type, and we've had some complaints
about that, take this as an opportunity to standardize on -O as a
short option equivalent for it.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
When a hex file contains some data that needs to be programmed using
the QSPI peripheral (because it targets the XIP region), nrfjprog
needs to be provided with an option that specifies the QSPI erase
method to be used (otherwise, reprogramming will fail).
This commit adds the "--qspisectorerase" option when needed and it
also fixes the programming routine for nRF53, so that data for the
XIP region is not incorrectly interpreted as intended for the network
core.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
nrfjprog prints out a warning if a device is programed without the
--verify option, which can be confusing.
So added the option when programming with nrfjprog.
Then west flash can be used without getting a warning.
Also changed the tests to only accept programming with --verify
option.
Signed-off-by: Markus Swarowsky <markus.swarowsky@nordicsemi.no>
In order to allow for further options to be deprecated with minimal
impact, add a deprecation argparse Action and a callable instantiator
that can be used to deprecate options in favor of new ones.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Set options that are definitely true or false to True or False in the
options dict. Add a 'getboolean' method that also allows a fallback to
False in case the option is not mentioned in .config due to unmet
dependencies. This allows calling code to just ask about the option
they are interested in, even if the .config file doesn't mention the
option at all.
Propagate this to users within the runners package and 'west sign',
taking advantage of the new build_conf property.
Rename the 'bcfg' internal variable in sign.py to 'build_conf' to
match other source files that use BuildConfiguration instances, to
make it easier to grep for users.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The commit fixes problem with nrfjprog runner for west flash,
that has been introduced with latest changes to BuildConfiguration
class.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
The nrfjprog utility is not capable of flashing a hex file which
affects the flash memories of both coprocessors of the nRF53 family of
SoCs.
However, the user is capable of creating such a hex file using the
HEX_FILES_TO_MERGE build system variable.
An example use case is to build a bluetooth controller application for
the network core, then use the zephyr.hex file in that build directory
as the HEX_FILES_TO_MERGE argument for a separate Bluetooth
application build targeting the app core.
Work around this by detecting the situation and doing the right thing
by splitting the hex file back up again, even if thats a bit awkward.
Splitting the hex into app and network core components allows them to
be flashed separately. This is the only way we can get the job done
with nrfjprog.
This is arguably nicer since there's just one 'west flash' invocation.
At least in the use case named above, you wouldn't need to rebuild the
controller application very often, so this is a simpler user workflow.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The RunnerConfig class stores the locations of the Zephyr output files
in various formats (elf, hex, bin). A longstanding issue with the
representation is that these might not exist if the corresponding
Kconfig options are not set. For example, if
CONFIG_BUILD_OUTPUT_BIN=n, there is no .bin file.
Change this so the type system knows these are Optional[str], not str.
Fix the runners that use non-ELF outputs so they check for the
existence of the relevant file before using it, mostly using a new
ZephyrBinaryRunner.ensure_output helper.
I'm not going to bother with checking for the ELF file itself; that's
always there as far as I can tell.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
It's fine to flash an image with UICR data as long as the user has
given any of the --erase, --recover, or --force options. Silence the
error correctly.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Rework the runner to improve various issues.
Every board.cmake file for an nRF SoC target is repeating boilerplate
needed for the nrfjprog runner's --nrf-family argument. The
information we need to decide the --nrf-family is already available in
Kconfig, so just get it from there instead. Keep the --nrf-family
argument around for compatibility, though.
This cuts boilerplate burden for board maintainers.
We also need to revisit how this runner handles recovery to fix it
in nRF53 and keep things consistent everywhere else.
To cleanly handle additional readback protection features in nRF53,
add a --recover option that does an 'nrfjprog --recover' before
flashing. Keep the behavior consistent across SoCs by supporting it on
those too. Because this is expected to be a bit tricky for users to
understand, check if a --recover is needed if the 'nrfjprog --program'
fails because of protection, and tell the user how to fix it.
Finally, instead of performing a separate 'nrfjprog --eraseall', just
give --chiperase to 'nrfjprog --program' process's arguments instead
of --sectorerase. This is cleaner, resulting in fewer subprocesses and
avoiding an extra chip reset.
Having a separate 'west flash --recover' option doubles the number of
test cases if we want to keep exhaustively enumerating them. That
doesn't feel worthwhile, so update the test cases by picking a
representative subset of the possibilities. Each test now has enough
state that it's worth wrapping it up in a named tuple for readability.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Inspect the hex file with intelhex, and fail if the hex file has any
contents in the UICR area(s).
family == 'NRF52' still always does --sectoranduicrerase, but this
option is not available on other families.
Add --force command line option to proceed with flashing instead of
failing.
Signed-off-by: Øyvind Rønningstad <oyvind.ronningstad@nordicsemi.no>
This is needed for sanitycheck hardware maps which take the serial
number directly from USB metadata.
Signed-off-by: Øyvind Rønningstad <oyvind.ronningstad@nordicsemi.no>
Pieter De Gendt
Carles Cufi
Grzegorz Swiderski
Jordan Yates
Gerard Marull-Paretas
Emanuele Di Santo
Tomasz Chyrowicz
Félix Piédallu
Tomasz Moń
Rafał Kuźnia
Witold Lukasik
Marti Bolivar
Gerard Marull-Paretas
Markus Swarowsky
Andrzej Głąbek
Dominik Ermel
Øyvind Rønningstad