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>
