public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Yao, Jiewen" <jiewen.yao@intel.com>
To: Samah Mansour <samah.mansour1@gmail.com>
Cc: "lersek@redhat.com" <lersek@redhat.com>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: SPI Flash Corruption
Date: Thu, 20 Sep 2018 23:43:49 +0000	[thread overview]
Message-ID: <BCA02244-7F87-4801-A98A-2AACFE776C4D@intel.com> (raw)
In-Reply-To: <CANzcc-fS+c_CynxgUdRQw_Rs7VUDqzpAxxwygnfo86Kk=cmaLQ@mail.gmail.com>

thank you, Samah. 
Would you please file a tracker in edkii bugzilla ?

The term VPD might lead confusion here. 
Ideally VPD region is independent with UEFI variable region. It is a special region to hold PCD with VPD type. 
I just look at the code. The open source minnowmax puts variable region in the VPD region. As such there is discussion about variable atomicity. But the variable atomicity cannot guarantee the integrity of FV header. Additional check need to be done in platform  FVB driver. 

If you can add a detailed reproducing step in the bugzilla, it will be helpful for us to understand the problem. 

thank you!
Yao, Jiewen


> 在 2018年9月20日,下午11:47,Samah Mansour <samah.mansour1@gmail.com> 写道:
> 
> Hi Laszlo,
> Thanks for your reply.
> Actually what I see is that VPD (Vital Product Area between addresses
> 44000->47DFF0  ) is completely wiped which causes the failure to boot!
> Without the VPD unit cannot boot.
> I will take a look at the white paper.
> It would be helpful to know what's the impact of disabling the ability of
> the firmware to write those non volatile variables to flash.
> 
> Samah
> 
> 
>> On Thu, Sep 20, 2018 at 9:48 AM Laszlo Ersek <lersek@redhat.com> wrote:
>> 
>>> On 09/19/18 16:26, Samah Mansour wrote:
>>> Hello,
>>> 
>>> 
>>> Our product uses a Baytrail with Minnowboard Max bios firmware ( version
>>> 0.93). Every now and then we see SPI flash corruption due to power cuts
>>> while the unit is booting which causes the unit not to boot anymore.
>> After
>>> investigation we noticed that the VPD area is all FFs (address
>>> 44000->47DFF0).
>>> 
>>> 
>>> We have noticed that the Bios while booting writes to the flash from
>>> several places in the code, which is if interrupted most probably is
>>> causing the corruption.
>>> 
>>> 
>>> Why is the bios writing all these configurations to flash while booting,
>> is
>>> it to optimize boot time? is it ok if we disable the bios writing to
>> flash
>>> completely to protect ourselves from corruption?
>> 
>> The firmware is at liberty to write various non-volatile UEFI variables
>> during boot. Some of those variables are standardized, some others may
>> be specific to UEFI drivers (with correspondingly private namespace
>> GUIDs for the variables).
>> 
>> Power loss during flash write (and resultant flash corruption) is
>> expected. My understanding is that the Fault Tolerant Write protocol /
>> driver, sitting between the FVB (firmware volume block, i.e. flash)
>> protocol / driver, and the variable write protocol / driver, implements
>> a kind of journaling. It is described in the Intel whitepaper
>> 
>>  A Tour Beyond BIOS
>>  Implementing UEFI Authenticated Variables in SMM with EDKII
>>  September 2015
>> 
>> My expectation has been that the platform should recover from
>> interrupted writes. That is, for a single given UEFI variable, you
>> should either see "before" or "after" status, never "middle". (The
>> whitepaper says that "Individual variable atomicity" is maintained even
>> through a failed "reclaim", with the help of FTW.)
>> 
>> If multiple variables should be in sync with each other, that's a
>> different question. If the variables are not in sync, I think "failure
>> to boot" may be a reasonable outcome. But, "failure to boot" means a lot
>> of things, and I hope one should be at least dropped to the setup
>> utility or the shell. Are you seeing an actual crash?
>> 
>> Laszlo
>> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

  reply	other threads:[~2018-09-20 23:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-19 14:26 SPI Flash Corruption Samah Mansour
2018-09-20 13:48 ` Laszlo Ersek
2018-09-20 15:47   ` Samah Mansour
2018-09-20 23:43     ` Yao, Jiewen [this message]
2018-09-21  9:26       ` Wei, David
2018-09-21 16:52         ` Andrew Fish
2018-09-21 17:18           ` Samah Mansour

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BCA02244-7F87-4801-A98A-2AACFE776C4D@intel.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox