Skip to content

docs/guides/redundancy.md: add#1218

Open
filipleple wants to merge 1 commit intomasterfrom
redundancy
Open

docs/guides/redundancy.md: add#1218
filipleple wants to merge 1 commit intomasterfrom
redundancy

Conversation

@filipleple
Copy link
Member

@filipleple filipleple commented Feb 4, 2026

issue: Dasharo/dasharo-issues#1487
ref: prot-1815

### Further reading

For a more detailed documentation of the implementation, please read the
[upstream coreboot documentation](WIP.com)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will have to wait for CB:90412 to get merged

Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
@filipleple filipleple marked this pull request as ready for review February 6, 2026 10:21
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You forgot to add this file to mkdocs.yml.


The problem addressed by this functionality is that when a platform's firmware
crashes during the boot process, the only mode of recovery is usually taking
apart the platform, attaching a SPI clip and flashing recovery firmware as per
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
apart the platform, attaching a SPI clip and flashing recovery firmware as per
apart the platform, attaching an SPI clip and flashing recovery firmware as per

Since letters are pronounced separately and the first one starts with a vowel sound.

Comment on lines +8 to +13
With the Top Swap A/B redundancy, there are two firmware slots - A and B,
of which A is a read-only golden copy, and B is the update partition. A
firmware update is going to target the B slot, and boot from it. Should the new
firmware fail, the platform can be brought back to life by performing a
**CMOS reset**, which will cause the platform to boot from the safe slot A
again.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
With the Top Swap A/B redundancy, there are two firmware slots - A and B,
of which A is a read-only golden copy, and B is the update partition. A
firmware update is going to target the B slot, and boot from it. Should the new
firmware fail, the platform can be brought back to life by performing a
**CMOS reset**, which will cause the platform to boot from the safe slot A
again.
With the Top Swap A/B redundancy, there are two firmware slots - **A** and **B**,
of which **A** is a read-only golden copy, and **B** is the update partition. A
firmware update is going to target the **B** slot, and boot from it. Should the new
firmware fail, the platform can be brought back to life by performing a
**CMOS reset**, which will cause the platform to boot from the safe slot **A**
again.

Otherwise "A" as a slot conflicts with "A" as an article.

physically topmost chunks of the BIOS flash chip, and decide in which order
to map them - effectively allowing to swap the two chunks.

* **A/B Slot Setup**: The firmware is divided into two slots: `BOOTBLOCK` and
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* **A/B Slot Setup**: The firmware is divided into two slots: `BOOTBLOCK` and
* **A/B Slot Setup**: The top of the firmware is divided into two slots: `BOOTBLOCK` and

To be more accurate.

these additional steps:

```bash
sudo flashrom -w coreboot.rom --fmap -i TOPSWAP -i COREBOOT_TS
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need -p internal? Don't remember it becoming optional.

Worth adding --noverify-all (-N) option? Otherwise active ME can cause verification failure.

## Further reading

For a more detailed documentation of the implementation, please read the
[upstream coreboot documentation](WIP.com)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit:

Suggested change
[upstream coreboot documentation](WIP.com)
[upstream coreboot documentation](WIP.com).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants