1======================================== 2Firmware updates vs SPI write-protection 3======================================== 4 5Enabling write-protection of any kind is meant to obstruct changing data, but it also limits 6what you can do to the part of firmware that's still writable. This document is meant to cover 7some of the origins of such limitations and situations which might arise after 8part of a flash chip has been protected. 9 10Firmware updates after locking bootblock 11======================================== 12 13This section is primarily concerned with :code:`coreboot` with bootblock being protected from writing, 14but similar problems can happen for any kind of firmware. 15 16Risks of partial updates 17------------------------ 18 19Partial updates can produce an unbootable image if an old bootblock doesn't work with a more recent 20version of :code:`coreboot`. This can be manifested in various ways ranging from an old bootblock not being able 21to find new romstage to system booting successfully but data in :code:`coreboot` tables being mangled or incomplete. 22 23The incompatibilities might happen when switching version of firmware or even when using the same version 24with a slightly different configuration. 25 26Another thing that can potentially cause trouble is CBFS layout. When bootblock is part of CBFS, 27it doesn't necessarily have a fixed address, moreover it can change location as well if it depends on file size 28(when bootblock's last byte must be the last byte of the image, which is the case on x86). If newer bootblock 29is smaller such that an old WP range now covers bootblock and some other file, this file won't be fully updated 30due to write-protection, potentially resulting in a corrupt image. Luckily, when bootblock is the last file 31it's normally preceded by a significant amount of empty space, which won't let this situation to occur. 32 33On top of that, last 4 bytes of the image contain offset to the master header of CBFS. Depending on 34the :code:`coreboot` version this offset might be crucial for the loading of romstage, in which case moving CBFS 35within the image without updating the offset (when it's locked by WP) can also prevent the system from booting. 36 37Recovering from a broken state 38------------------------------ 39 40Since broken flash won't let the system to boot, the way to fix it is to flash the chip externally by connecting 41it to a different device. A possible alternative could be to have a backup flash created beforehand and swapping 42it for the broken one (not very applicable if swapping doesn't require soldering). There are also some mainboards 43with dual flash chips one of which acts as a backup that can be restored by holding power on button long enough. 44 45Flashing whole firmware image 46============================= 47 48The function of the hardware protection mechanism (:code:`W#` or :code:`W/` pin of flash chips) is to lock state of 49software protection thus preventing it from being disabled. After the chip is physically unlocked by changing 50the state of the pin, the state of the write protection doesn't change. However, in this state the protection 51can be easily turned off programmatically, which is what :code:`flashrom` tries to do before performing an operation on a chip. 52 53In other words, changing state of the WP pin might be enough to be able to flash the chip in full. 54If :code:`flashrom` errors or you don't want to rely on the automatic behaviour, you can try to 55explicitly disable the protection by running :code:`flashrom` like this:: 56 57 flashrom --wp-disable 58 59If you need to pass extra parameters to flash your chip (e.g., programmer or chip name), add them to the above command 60(order of such parameters shouldn't matter). 61