Speed up firmware updates by NickeZ · Pull Request #2002 · BitBoxSwiss/bitbox02-firmware

NickeZ · 2026-06-30T08:14:30Z

Approximately halfs the current flashing time to 55s.

Erase the full firmware area on OP_ERASE, then flash 4 KiB firmware chunks.

benma

Seems overly complicated, I think the cache/flush is not needed?

Why not just erase in OP_ERASE, and just use flash_append with 4kB chunks during flashing?

Also reject signature data before all declared firmware chunks have been received and flushed.

Why? One can't successfully do it anyway beforehand, as that API call rejects on invalid signatures. Can't hurt but seems not needed.

adam2k

I'm new here and disclaimer up front I do not have a dev device, so I am doing static analysis only.

@benma asked whether the cache is needed. I believe it is not, and the HAL explains the speedup: flash_write -> _flash_write (hpl_nvmctrl.c:158) is read-modify-write per 8 kB block, so two 4 kB chunks cost two erase-and-reprogram cycles. flash_append -> _flash_append (:204) programs page by page with no erase. Chunks sit at FLASH_APP_START + n*4096 with FLASH_APP_START == 0x10000, so they're always page-aligned. After the upfront erase, plain flash_append per chunk should be enough.

Two branches in the current shape already look dead as a result. I've noted those inline.

adam2k · 2026-08-03T13:52:07Z

+        return OP_STATUS_OK;
+    }
+
+    if (_firmware_app_erased || _is_erased((const void*)addr, FIRMWARE_BLOCK_LEN)) {


This branch looks unreachable. _firmware_app_erased is cleared only at 588, immediately after _loading_ready = false (586), and set true at 604 before _loading_ready = true (608). _api_write_chunk requires _loading_ready on entry and only re-arms it on success, so _loading_ready implies _firmware_app_erased. Both the _is_erased() call and the flash_write branch below are dead.

thanks, not applicable anymore.

adam2k · 2026-08-03T13:52:59Z

+    }
+
+    const uint32_t addr = FLASH_APP_START + _firmware_cached_block * FIRMWARE_BLOCK_LEN;
+    if (MEMEQ((const void*)addr, _firmware_block_cache, FIRMWARE_BLOCK_LEN)) {


Near-dead: post-erase the block is 0xFF and each block is written once, so this only hits on an all-0xFF chunk pair, at the cost of an 8 kB compare per block. The old per-chunk MEMEQ paid for itself because flash wasn't pre-erased.

thanks, not applicable anymore.

adam2k · 2026-08-03T13:53:45Z

-    if (chunknum > _firmware_num_chunks - 1 || chunknum > FIRMWARE_MAX_NUM_CHUNKS - 1) {
+    // The second is redundant, as _firmware_num_chunks <= FIRMWARE_MAX_NUM_CHUNKS.
+    if (chunknum > _firmware_num_chunks - 1 || chunknum > FIRMWARE_MAX_NUM_CHUNKS - 1 ||
+        chunknum != _firmware_next_chunk) {


This makes out-of-order writes a hard error, tightening the host protocol permanently in the bootloader. bootloader.py:191 is sequential so the bundled client is fine, but worth confirming BitBoxApp is too, and that it's intended as a contract change.

thanks, not applicable anymore.

adam2k · 2026-08-03T13:55:00Z

-        if (!MEMEQ((const void*)addr, empty_page, sizeof(empty_page))) {
-            return _report_status(OP_STATUS_ERR_CHECK, output);
+
+    for (uint32_t addr = FLASH_APP_START; addr < FLASH_APP_START + FLASH_APP_LEN;


This erases 864 kB (108 blocks) in one blocking call, where previously a full-size firmware erased almost nothing here. Any host-side timeout on OP_ERASE? _render_progress(0) is also drawn before the loop, so the screen sits at 0% throughout. Disclaimer: I do not have a dev device, so I can't measure it.

I haven't noticed any issues in testing.

That call to _render_progress(0) was probably removed, so now it sits at "Upgrading" instead.

adam2k · 2026-08-03T13:55:33Z

            bootloader_render_default_screen();
        } else {
-            _render_progress((float)chunk_num / (float)(_firmware_num_chunks - 1));
+            float progress = 1;


Real fix rather than cleanup: at _firmware_num_chunks == 1 the old expression is 0/0 = NaN. Unrelated to the caching change, so maybe its own commit.

adam2k · 2026-08-03T14:00:57Z

Why not just erase in OP_ERASE, and just use flash_append with 4kB chunks during flashing?

+1 for the above comment. _api_write_sig_data -> _set_firmware_data -> _firmware_verified_jump() verifies over what's actually in flash, so an incomplete firmware fails there regardless.

NickeZ · 2026-08-25T08:02:00Z

Simplified PR. Still flashes in 55 seconds. It is on "Upgrading" screen while erasing for about 4-5 seconds. It doesn't stand still at 0%.

Erase the whole app flash area up front. Append each 4 KiB firmware chunk directly when received. Allow arbitrary chunk order and reject writes to non-erased ranges.

Render one-chunk firmware updates as complete without evaluating the progress ratio with a zero denominator.

NickeZ · 2026-08-31T16:17:58Z

Simplified PR. Still flashes in 55 seconds. It is on "Upgrading" screen while erasing for about 4-5 seconds. It doesn't stand still at 0%.

Actually flashing only takes about 60 seconds. So there is more like a 10% upgrade. I guess we already removed a lot of double work in some earlier PR.

NickeZ requested a review from benma June 30, 2026 08:14

benma reviewed Jul 2, 2026

View reviewed changes

adam2k reviewed Aug 3, 2026

View reviewed changes

NickeZ force-pushed the nickez/erase-first-then-flash branch from 1185c09 to 1956603 Compare August 25, 2026 07:55

NickeZ changed the title ~~Cache bootloader firmware writes~~ Speed up firmware updates Aug 25, 2026

NickeZ added 2 commits August 31, 2026 15:02

Erase firmware before writing chunks

4497067

Erase the whole app flash area up front. Append each 4 KiB firmware chunk directly when received. Allow arbitrary chunk order and reject writes to non-erased ranges.

Avoid zero division in bootloader

64c9d84

Render one-chunk firmware updates as complete without evaluating the progress ratio with a zero denominator.

NickeZ force-pushed the nickez/erase-first-then-flash branch from db26bae to 64c9d84 Compare August 31, 2026 13:02

Uh oh!

Conversation

NickeZ commented Jun 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

benma left a comment

Choose a reason for hiding this comment

Uh oh!

adam2k left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

adam2k commented Aug 3, 2026

Uh oh!

NickeZ commented Aug 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

NickeZ commented Aug 31, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

NickeZ commented Jun 30, 2026 •

edited

Loading

NickeZ commented Aug 25, 2026 •

edited

Loading