Hello coreboot community members,
This is a follow-up to my colleague Michał Żygowski's RFC concerning
redundancy of the bootblock, mainly on recent Intel-based platforms.
We've
taken your feedback and would like to present another proposal to you.
The goal of this feature is to prevent accidental bricks caused by
flashing a
bad firmware image, by providing a secondary copy of boot firmware that
acts as
a fallback path for main firmware. The general idea is that if a user
flashes
bad firmware or the update goes wrong, you can always restore
functioning
firmware by resetting the CMOS.
On Intel, this is realized by the Top Swap mechanism, where the top
range of
the flash (of configurable size, from 64K to more than 1M in latest
chipsets)
can be swapped between two copies. At this point support for other
architectures has not been considered, so initially this would be an
Intel-only
feature.
I find it easiest to show an example FMAP first and then describe
what's going
on:
FLASH 32M {
SI_ALL 10M {
SI_DESC 16K
#if CONFIG_MAINBOARD_USES_IFD_GBE_REGION
SI_GBE 8K
#endif
SI_ME
}
RW_UNUSED 6M
SI_BIOS {
RW_MISC {
RW_MRC_CACHE 64K
SMMSTORE(PRESERVE) 256K
}
RW_PAD
FW_MAIN_B(CBFS) 6M
FW_MAIN_A(CBFS) 6M
FMAP 2K
TOPSWAP_B(CBFS) 512K
TOPSWAP_A(CBFS) 512K
}
}
In this example:
- The FMAP region is not redundant and it is suggested that this region
not
change for the lifetime of the platform, to make sure the redundancy
code
works properly.
- There are two bootblocks and two FW_MAIN sections which together
establish
Slot A and Slot B
- Topswap regions are CBFSes that contain the bootblocks and ACMs if
used by
the build
- ACMs are also why their sizes in this example are configured to 512K
- SMMSTORE and MRC cache do not need to be and aren't covered by
redundancy
- Initially, the platform boots from Slot A only
- Slot A firmware is unchanging and may be protected by chipset
protection
mechanisms (PRx registers on Intel based platforms)
- The update flow
- User attempts to update slot B, e.g. by flashrom
- User sets the Attempt Slot B flag e.g. by nvramtool
- User reboots the platform
- Slot A firmware sees the Attempt Slot B flag, sets the Top Swap bit
in the
PCH and resets the platform
- Slot B firmware is booted
- Recovery flow
- User resets the CMOS
- alternatively: attempt counter in CMOS, or watchdog resets the
flags
- Slot A firmware boots
There is also an option to have an updatable Slot A.
- The modified update flow:
- User initiates update of Slot B e.g. by flashrom
- User sets the Attempt Slot B flag e.g. by nvramtool
- User reboots the platform
- Slot A firmware sees the Attempt Slot B flag and sets the Top Swap
bit
- Slot B proceeds to boot into the payload and assesses that the boot
was
successful as late as possible (e.g. by UEFI EBS) by setting the
Slot B
Successful flag in CMOS
- User eventually reboots the platform
- Slot B firmware sees the update successful flag and overwrites Slot A
with contents of Slot B
Looking forward to your feedback on this proposal :)
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
