Flashing coreboot and Intel Flash Descriptor Erase Issue

[Balaji Sivakumar]

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?

[Peter Stuge]

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

[Balaji Sivakumar]

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  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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

[David Hendricks]

On Sun, Oct 18, 2020 at 8:52 AM Balaji Sivakumar 
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 Sivakumar]

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 
wrote:
> On Sun, Oct 18, 2020 at 8:52 AM Balaji Sivakumar 
> 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 Sivakumar]

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 
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 
> wrote:
> > On Sun, Oct 18, 2020 at 8:52 AM Balaji Sivakumar <
> > [e-mail]> 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).

[David Hendricks]

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).
>

[Balaji Sivakumar]

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 
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).
> >

[David Hendricks]

Hi Balaji,

On Tue, Nov 3, 2020 at 10:03 PM Balaji Sivakumar 
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().

[Naresh G. Solanki]

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 
wrote:
> Hi Balaji,
>
> On Tue, Nov 3, 2020 at 10:03 PM Balaji Sivakumar 
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Balaji Sivakumar]

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 <
[e-mail]> 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 <
> [e-mail]> wrote:
> > Hi Balaji,
> >
> > On Tue, Nov 3, 2020 at 10:03 PM Balaji Sivakumar <
> > [e-mail]> 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]