Flashing coreboot and Intel Flash Descriptor Erase Issue
We are using SPI flash(Macronix) to program the BIOS. And we use an external programmer to flash the BIOS (coreboot including FD+ME) into SPI Flash (16384 kB, SPI), it works fine and boots well. The board is functional and we have successfully booted a kernel on it. Am working on adding a feature to upgrading the BIOS (complete IFD+ME+Coreboot) using intel-spi driver at the OS level. Able to successfully take the backup full 16MB spi nor flash data which includes IFD+ME+BIOS using flashrom Internal Programmer option and it is identified as Opaque flash chip and using dd command as well. But we are seeing the erase fail through both flashrom and flash_erase utility. I believe it fails to erase at the flash descriptor location. As far as Read/Write access to the SPI regions, I have enabled the Host CPU BIOS write access and ME Master Access as 0xFFFF through Intel FIT Tool but still not able to erase it and it fails. Is there anything that could be preventing to enable read/write access to the Intel flash descriptor or any SOC SPI controller protection to access the Flash descriptor? -- Thanks, Balaji
Balaji Sivakumar wrote:
Am working on adding a feature to upgrading the BIOS (complete IFD+ME+Coreboot) using intel-spi driver at the OS level. Able to successfully take the backup full 16MB spi nor flash data which includes IFD+ME+BIOS using flashrom Internal Programmer option and it is identified as Opaque flash chip and using dd command as well.
I believe identified as "Opaque flash chip" means that no positive identification was possible - this means that flashrom is not able to perform all the SPI commands it needs using this programmer method (internal) on this system. I added a warning message to the flashrom output many years ago when a flash chip could not be positively identified, which said that erase and quite possibly also write can never work unless the chip is correctly identified.
But we are seeing the erase fail through both flashrom and flash_erase utility. I believe it fails to erase at the flash descriptor location.
As far as Read/Write access to the SPI regions, I have enabled the Host CPU BIOS write access and ME Master Access as 0xFFFF through Intel FIT Tool but still not able to erase it and it fails.
Is there anything that could be preventing to enable read/write access to the Intel flash descriptor or any SOC SPI controller protection to access the Flash descriptor?
I guess that since you work on a platform with ME hardware it is not intended to allow what you want to do. As a first step you could try erasing the BIOS flash region, but I don't think that can work until flashrom successfully identifies the actual flash chip you are using. How to get there is unclear, but do run flashrom with verbose output and see if the OPMENU contains the SPI commands needed to identify, erase and write. I guess it might not. //Peter
Thank you Peter for the details. Yes it is identifying it as opaque flash chip. We are able to completely read it but erase fails. I have unloaded the intel spi driver and added a support in flashrom for intel denverton. I could see still it identify as opaque flash chip. I understood from the logs of flashrom that SMM protection is enabled. Working on it to disable it. Thanks Balaji On Fri, Oct 16, 2020 at 8:11 AM Peter Stuge <peter@stuge.se> wrote:
Balaji Sivakumar wrote:
Am working on adding a feature to upgrading the BIOS (complete IFD+ME+Coreboot) using intel-spi driver at the OS level. Able to successfully take the backup full 16MB spi nor flash data which includes IFD+ME+BIOS using flashrom Internal Programmer option and it is identified as Opaque flash chip and using dd command as well.
I believe identified as "Opaque flash chip" means that no positive identification was possible - this means that flashrom is not able to perform all the SPI commands it needs using this programmer method (internal) on this system.
I added a warning message to the flashrom output many years ago when a flash chip could not be positively identified, which said that erase and quite possibly also write can never work unless the chip is correctly identified.
But we are seeing the erase fail through both flashrom and flash_erase utility. I believe it fails to erase at the flash descriptor location.
As far as Read/Write access to the SPI regions, I have enabled the Host CPU BIOS write access and ME Master Access as 0xFFFF through Intel FIT Tool but still not able to erase it and it fails.
Is there anything that could be preventing to enable read/write access to the Intel flash descriptor or any SOC SPI controller protection to access the Flash descriptor?
I guess that since you work on a platform with ME hardware it is not intended to allow what you want to do.
As a first step you could try erasing the BIOS flash region, but I don't think that can work until flashrom successfully identifies the actual flash chip you are using. How to get there is unclear, but do run flashrom with verbose output and see if the OPMENU contains the SPI commands needed to identify, erase and write. I guess it might not.
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Thanks, Balaji +1-319-573-9768
On Sun, Oct 18, 2020 at 8:52 AM Balaji Sivakumar <shivbalaji1985@gmail.com> wrote:
Thank you Peter for the details. Yes it is identifying it as opaque flash chip. We are able to completely read it but erase fails.
There is some documentation in the tree to help explain the "opaque flash chip": https://review.coreboot.org/cgit/flashrom.git/tree/Documentation/mysteries_i...
I understood from the logs of flashrom that SMM protection is enabled. Working on it to disable it.
You will also need to enable host CPU write access to other regions you with to be writeable. From your earlier e-mail it appears that you've already done this for the ME region, however you'll need to do it for IFD and other regions you wish to update. Be advised, however, that *not* locking certain regions may cause the ME to behave differently. You can also target specific regions for updates using `--ifd -i <region> -N`, for example `--ifd -i bios -N` will make flashrom only attempt to write and verify the BIOS region (without -N flashrom will attempt to verify the entire chip contents).
There is some documentation in the tree to help explain the "opaque flash chip": https://review.coreboot.org/cgit/flashrom.git/tree/Documentation/mysteries_i... - Thank you David for the details, I will go through this. You will also need to enable host CPU write access to other regions you with to be writeable. From your earlier e-mail it appears that you've already done this for the ME region, however you'll need to do it for IFD and other regions you wish to update. Be advised, however, that *not* locking certain regions may cause the ME to behave differently. - I have enabled Read write access to the Host CPU Bios, Intel ME and have verified it in the flash descriptor file as well. Also I have unlocked it again using IFDtool as well. You can also target specific regions for updates using `--ifd -i <region> -N`, for example `--ifd -i bios -N` will make flashrom only attempt to write and verify the BIOS region (without -N flashrom will attempt to verify the entire chip contents). - Sure I will try with -N option. I have tried it without the N option and Bios section alone,It failed to erase. I could see from the logs BIOS region SMM protection is enabled and changing it to writable at Bios control failed(Warning: Setting Bios Control at 0xdc from 0xab to 0x89 failed).It remains with oldervalue. On Sun, Oct 18, 2020 at 2:42 PM David Hendricks <david.hendricks@gmail.com> wrote:
On Sun, Oct 18, 2020 at 8:52 AM Balaji Sivakumar <shivbalaji1985@gmail.com> wrote:
Thank you Peter for the details. Yes it is identifying it as opaque flash chip. We are able to completely read it but erase fails.
There is some documentation in the tree to help explain the "opaque flash chip": https://review.coreboot.org/cgit/flashrom.git/tree/Documentation/mysteries_i...
I understood from the logs of flashrom that SMM protection is enabled. Working on it to disable it.
You will also need to enable host CPU write access to other regions you with to be writeable. From your earlier e-mail it appears that you've already done this for the ME region, however you'll need to do it for IFD and other regions you wish to update. Be advised, however, that *not* locking certain regions may cause the ME to behave differently.
You can also target specific regions for updates using `--ifd -i <region> -N`, for example `--ifd -i bios -N` will make flashrom only attempt to write and verify the BIOS region (without -N flashrom will attempt to verify the entire chip contents).
-- Balaji
I have added Denverton support in the flashrom and I found that SMM Protection is enabled from the logs. I have tried to disable it using setcpi utility and it remains the same value. Also the flashrom utility also tries but it remains the same. Warning: BIOS region SMM protection is enabled! Warning: Setting Bios Control at 0xdc from 0xab to 0x89 failed. Also FLOCKDN=1 is set as 1 as well. I can clearly tell the BIOS region is read and writable but Protected registers are read only that's also the reason I am not able to write the BIOS region. What are the options/methods to unlock / disable the Bios Write enable(BIOS_CNTL) or to access the HSFS registers to set the FLOCKDN bit to 0. Any pointers would be appreciated! On Sun, Oct 18, 2020 at 4:20 PM Balaji Sivakumar <shivbalaji1985@gmail.com> wrote:
There is some documentation in the tree to help explain the "opaque flash chip": https://review.coreboot.org/cgit/flashrom.git/tree/Documentation/mysteries_i...
- Thank you David for the details, I will go through this.
You will also need to enable host CPU write access to other regions you with to be writeable. From your earlier e-mail it appears that you've already done this for the ME region, however you'll need to do it for IFD and other regions you wish to update. Be advised, however, that *not* locking certain regions may cause the ME to behave differently.
- I have enabled Read write access to the Host CPU Bios, Intel ME and have verified it in the flash descriptor file as well. Also I have unlocked it again using IFDtool as well.
You can also target specific regions for updates using `--ifd -i <region> -N`, for example `--ifd -i bios -N` will make flashrom only attempt to write and verify the BIOS region (without -N flashrom will attempt to verify the entire chip contents).
- Sure I will try with -N option. I have tried it without the N option and Bios section alone,It failed to erase. I could see from the logs BIOS region SMM protection is enabled and changing it to writable at Bios control failed(Warning: Setting Bios Control at 0xdc from 0xab to 0x89 failed).It remains with oldervalue.
On Sun, Oct 18, 2020 at 2:42 PM David Hendricks <david.hendricks@gmail.com> wrote:
On Sun, Oct 18, 2020 at 8:52 AM Balaji Sivakumar < shivbalaji1985@gmail.com> wrote:
Thank you Peter for the details. Yes it is identifying it as opaque flash chip. We are able to completely read it but erase fails.
There is some documentation in the tree to help explain the "opaque flash chip": https://review.coreboot.org/cgit/flashrom.git/tree/Documentation/mysteries_i...
I understood from the logs of flashrom that SMM protection is enabled. Working on it to disable it.
You will also need to enable host CPU write access to other regions you with to be writeable. From your earlier e-mail it appears that you've already done this for the ME region, however you'll need to do it for IFD and other regions you wish to update. Be advised, however, that *not* locking certain regions may cause the ME to behave differently.
You can also target specific regions for updates using `--ifd -i <region> -N`, for example `--ifd -i bios -N` will make flashrom only attempt to write and verify the BIOS region (without -N flashrom will attempt to verify the entire chip contents).
-- Balaji
-- Thanks, Balaji +1-319-573-9768
Hi Balaji, I have tried to disable it using setcpi utility and it remains the same
value. Also the flashrom utility also tries but it remains the same.
Warning: BIOS region SMM protection is enabled! Warning: Setting Bios Control at 0xdc from 0xab to 0x89 failed.
Also FLOCKDN=1 is set as 1 as well.
I can clearly tell the BIOS region is read and writable but Protected registers are read only that's also the reason I am not able to write the BIOS region.
What are the options/methods to unlock / disable the Bios Write enable(BIOS_CNTL) or to access the HSFS registers to set the FLOCKDN bit to 0.
Since BIOS_CNTL is 0xab, the SMM_BWP, BLE, and BIOSWE bits are set. This means that you can only write to the BIOS region from within SMM. You should not be able to change this from userspace. The BLE and BIOSWE bits are not set by default. You mentioned that you're using coreboot, can you check the source code to see if BIOS_CNTL is getting set anywhere? You can also check if FLOCKDN is getting set, possibly by FSP (look for the SpiFlashCfgLockDown FSP parameter getting set).
Hi David, Have verified and confirmed that coreboot process as well, it is disabling the BIOS write protect and Enable Prefetching and Caching as part of fast_spi_init(). /* Disable the BIOS write protect so write commands are allowed. */ bios_cntl &= ~SPIBAR_BIOS_CONTROL_EISS; bios_cntl |= SPIBAR_BIOS_CONTROL_WPD; /* Enable Prefetching and caching. */ bios_cntl |= SPIBAR_BIOS_CONTROL_PREFETCH_ENABLE; bios_cntl &= ~SPIBAR_BIOS_CONTROL_CACHE_DISABLE; -Balaji On Mon, Oct 26, 2020 at 1:08 AM David Hendricks <david.hendricks@gmail.com> wrote:
Hi Balaji,
I have tried to disable it using setcpi utility and it remains the same
value. Also the flashrom utility also tries but it remains the same.
Warning: BIOS region SMM protection is enabled! Warning: Setting Bios Control at 0xdc from 0xab to 0x89 failed.
Also FLOCKDN=1 is set as 1 as well.
I can clearly tell the BIOS region is read and writable but Protected registers are read only that's also the reason I am not able to write the BIOS region.
What are the options/methods to unlock / disable the Bios Write enable(BIOS_CNTL) or to access the HSFS registers to set the FLOCKDN bit to 0.
Since BIOS_CNTL is 0xab, the SMM_BWP, BLE, and BIOSWE bits are set. This means that you can only write to the BIOS region from within SMM. You should not be able to change this from userspace.
The BLE and BIOSWE bits are not set by default. You mentioned that you're using coreboot, can you check the source code to see if BIOS_CNTL is getting set anywhere? You can also check if FLOCKDN is getting set, possibly by FSP (look for the SpiFlashCfgLockDown FSP parameter getting set).
--
Hi Balaji, On Tue, Nov 3, 2020 at 10:03 PM Balaji Sivakumar <shivbalaji1985@gmail.com> wrote:
Hi David,
Have verified and confirmed that coreboot process as well, it is disabling the BIOS write protect and Enable Prefetching and Caching as part of fast_spi_init().
Were you able to figure this one out? The snippet you showed is from fast_spi_init() which should get called once early on. It is possible that something later on calls fast_spi_enable_wp(), perhaps smihandler_soc_check_illegal_access().
Hi Balaji, I see that SPI BIOS_CTRL.LE bit is set. It can be set by either Coreboot or FSP. I guess it might be getting set by FSP. Can you add printk in file "src/soc/intel/denverton_ns/chip.c" at the line 46 before & after fsp_silicon_init to print bios control reg. This will help in understanding whether fsp is doing it or not. If SOC_INTEL_COMMON_PCH_LOCKDOWN config is enabled in your build then src/soc/intel/common/block/fast_spi/fast_spi.c +102 here it might be getting locked. Also you can enable debug log in smi handler & print bios control reg select this in menuconfig CONFIG_DEBUG_SMI If possible, provide a log with above debug prints to understand where the lock enable bit is getting set. Regards, Naresh Solanki On Tue, Nov 10, 2020 at 12:40 PM David Hendricks <david.hendricks@gmail.com> wrote:
Hi Balaji,
On Tue, Nov 3, 2020 at 10:03 PM Balaji Sivakumar <shivbalaji1985@gmail.com> wrote:
Hi David,
Have verified and confirmed that coreboot process as well, it is disabling the BIOS write protect and Enable Prefetching and Caching as part of fast_spi_init().
Were you able to figure this one out? The snippet you showed is from fast_spi_init() which should get called once early on. It is possible that something later on calls fast_spi_enable_wp(), perhaps smihandler_soc_check_illegal_access(). _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Naresh G. Solanki
Hi Naresh and David, I see that SPI BIOS_CTRL.LE bit is set. It can be set by either Coreboot or FSP. I guess it might be getting set by FSP. Can you add printk in file "src/soc/intel/denverton_ns/chip.c" at the line 46 before & after fsp_silicon_init to print bios control reg. This will help in understanding whether fsp is doing it or not. Sure will add and share the logs. We are very sure that SPI BIOS_CTRL is set by FSP. If SOC_INTEL_COMMON_PCH_LOCKDOWN config is enabled in your build then src/soc/intel/common/block/fast_spi/fast_spi.c +102 here it might be getting locked. I double checked it, we are not enabling this config in our build. Also you can enable debug log in smi handler & print bios control reg select this in menuconfig CONFIG_DEBUG_SMI Sure, I will add and test it. Thanks Balaji On Tue, Nov 10, 2020 at 9:49 AM Naresh G. Solanki < naresh.solanki.2011@gmail.com> wrote:
Hi Balaji,
I see that SPI BIOS_CTRL.LE bit is set. It can be set by either Coreboot or FSP. I guess it might be getting set by FSP. Can you add printk in file "src/soc/intel/denverton_ns/chip.c" at the line 46 before & after fsp_silicon_init to print bios control reg. This will help in understanding whether fsp is doing it or not.
If SOC_INTEL_COMMON_PCH_LOCKDOWN config is enabled in your build then src/soc/intel/common/block/fast_spi/fast_spi.c +102 here it might be getting locked.
Also you can enable debug log in smi handler & print bios control reg select this in menuconfig CONFIG_DEBUG_SMI
If possible, provide a log with above debug prints to understand where the lock enable bit is getting set.
Regards, Naresh Solanki
On Tue, Nov 10, 2020 at 12:40 PM David Hendricks < david.hendricks@gmail.com> wrote:
Hi Balaji,
On Tue, Nov 3, 2020 at 10:03 PM Balaji Sivakumar < shivbalaji1985@gmail.com> wrote:
Hi David,
Have verified and confirmed that coreboot process as well, it is disabling the BIOS write protect and Enable Prefetching and Caching as part of fast_spi_init().
Were you able to figure this one out? The snippet you showed is from fast_spi_init() which should get called once early on. It is possible that something later on calls fast_spi_enable_wp(), perhaps smihandler_soc_check_illegal_access(). _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Naresh G. Solanki
participants (4)
-
Balaji Sivakumar -
David Hendricks -
Naresh G. Solanki -
Peter Stuge