west flash --nobuild, west flash-signed

[novalisek]

Hi,
I didn't found a way how to just "flash" without building project again, I think it would be useful.
Now when using mcuboot, I do:

west build
west sign -t imgtool -- --key xxxx.pem
west flash -- --hex-file build/zephyr/zephyr.signed.hex

But west flash is building the project again ...

Or may be thre could be command west flash-signed that would flash the default signed file, without building. And may be some option in project.yaml, that could point to key file, and then you could do something like

west build-signed - that would build + sign
west flash-signed - that would take the signed file and flash it

I know I can make .cmd or powershell scripts in windows to make all of this, but at least "--no-build" option would be useful.

[mbolivar]

Hello,

Since build, flash, and debug are extensions defined in the zephyr repository, I've made this a zephyr issue, not a west issue.

I didn't found a way how to just "flash" without building project again, I think it would be useful.

You can use west flash --skip-rebuild. Tip: run west flash --help for help on available options.

Please reopen if there's something I've missed.

[novalisek]

Sorry for not using west flash --help, I was just doing west --help.
And is it bad idea to automaticaly disable rebuild when running west flash with --hex-file parameter? Now I don't see any reason for rebuilding when using other file, than the one that is created by rebuild. But may be it could cause trouble somewhere else, just the idea ...

[mbolivar]

Sorry for not using west flash --help, I was just doing west --help.

That's okay!

By the way, this is the last line printed by west --help:

Run "west help <command>" for help on each <command>.

The output for west help flash is currently the same as the west flash --help I suggested, in case you were wondering.

And is it bad idea to automaticaly disable rebuild when running west flash with --hex-file parameter? > Now I don't see any reason for rebuilding when using other file, than the one that is created by rebuild. But may be it could cause trouble somewhere else, just the idea ...

The flash and debug commands bring the targets they depend on up to date in order to match the build system commands by the same name (that is, both west flash and ninja flash bring the build targets they depend on up to date).

If your binaries are already up to date, there's no problem with using --skip-rebuild. It's up to you to decide what you'd prefer to use. Rebuilding shouldn't take long if there's nothing to do, so there won't be a big performance benefit.

[novalisek]

Ok, I will continue to use --skip-rebuild if it cannot be done automaticaly when external binary is specified.
Is it also bad idea to have something like CONFIG_MCUBOOT_PEM in prj.conf to point to .pem file and have
west build-signed to build and sign the binary and then west flash-signed to automaticaly select signed binary and flash it without rebuild?

Also west build on already up-to date project takes around 25sec (W10 + arm toolochain) ... thats not so small time, normaly "make" I sometimes use on my projects, would take 0sec if it was run for 2nd time without no changes in source files.

[mbolivar]

west build-signed to build and sign the binary and then west flash-signed to automaticaly select signed binary and flash it without rebuild?

If you're doing this on an application-specific basis, I think you could probably set a custom --hex-file argument in the build system using board_set_runner_args(), no?

Also west build on already up-to date project takes around 25sec (W10 + arm toolochain) ... thats not so small time, normaly "make" I sometimes use on my projects, would take 0sec if it was run for 2nd time without no changes in source files.

I can't reproduce this on my windows 10 machine with ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb when building hello world. Even on Windows, a fresh rebuild takes under a second.

Perhaps your application has a custom target which is always out of date?

[novalisek]

Sorry, it's W7, not W10, I am running W7 guest in W10 host under Virtualbox.

GNUARMEMB_TOOLCHAIN_PATH=C:\gnu_arm_embedded
ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb

cmd.exe
d:
cd d:\xxxx\zephyr
zephyr-env.cmd
cd samples\hello_world

west build -b nrf52_pca10040 - fresh build takes around 40 sec
anotherwest build - takes around 15sec
It is doing 122 steps in first run, and 88 steps in second ... so there is some change, should it do 0 (or very few) steps or 88 steps, but very fast?

I shall try on fresh W10, I have some othere devel. tools in that W7, so may be there is some conflict. Or may be it's just slow CPU because it's in Virtualbox ...

If it only took few secs, I wouldn't bother creating this issue at all :)

[mbolivar]

If a no-op build takes more than a fraction of a second on a currently supported version of Windows (note that as far as I know, Windows 7 is not officially supported since Microsoft EOLed it), that's a build system bug for sure. Please let me know if you see it on Windows 10.