From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=17.151.62.68; helo=nwk-aaemail-lapp03.apple.com; envelope-from=afish@apple.com; receiver=edk2-devel@lists.01.org Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 60BEF211546E6 for ; Fri, 21 Sep 2018 09:53:20 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.22/8.16.0.22) with SMTP id w8LGqBgK060838; Fri, 21 Sep 2018 09:53:18 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=OLJB8RiEJA2OhXC3LxnH198Jn62CKaNtDl/87Mji6BI=; b=d1g+KWDS9vTD1ZEMkCH9G/NBwX9WdKpVCvlHch8E9NSN4dq1HCtqwd4X4zhuI74O+Vg/ 7PjJKmeHAily5D7AMV7np/lP1aGESxKLamR+dEZziiNNxOZvDK/bbrXQZ5+eF4o/hSTh OOkVsfVYFbSgR2fddH6H4+2U24ea0TA8LQFYUEPt4zf8sdOhThsHaZqXoiGGKnJFuxYI m0kRHxU/IppnfzkoPZgiFe8G5hCcGm3p+uwHwO9RElOpO5pepxIlOXFzHGovCAbv7Sva v6+WL6opYAvW32r+lCX02V5EfC6Rj8zAeQqGI4cMh5MvShFZsKt9HSMSmhtdwMW9u8dP hg== Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2mmkmcvywd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 21 Sep 2018 09:53:18 -0700 MIME-version: 1.0 Received: from ma1-mmpp-sz09.apple.com (ma1-mmpp-sz09.apple.com [17.171.128.183]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PFF006GL08TXB90@mr2-mtap-s02.rno.apple.com>; Fri, 21 Sep 2018 09:53:17 -0700 (PDT) Received: from process_viserion-daemon.ma1-mmpp-sz09.apple.com by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PFE00500ZSBF500@ma1-mmpp-sz09.apple.com>; Fri, 21 Sep 2018 09:53:17 -0700 (PDT) X-Va-A: X-Va-T-CD: 242eef930ced4d4f7f74b6d5f343603a X-Va-E-CD: 904fe4f32cfecc195257d7f0673a5444 X-Va-R-CD: 37335104b4c92f680d4b19f6eee48d55 X-Va-CD: 0 X-Va-ID: 4877b8f1-76f5-4c2b-9021-7459214f290a X-V-A: X-V-T-CD: 9ef9aac75985bbd8c956b46e6a20b6e1 X-V-E-CD: 904fe4f32cfecc195257d7f0673a5444 X-V-R-CD: 37335104b4c92f680d4b19f6eee48d55 X-V-CD: 0 X-V-ID: df9bc4ee-35bb-4dd1-a9a7-c92fe93fedb2 Received: from process_milters-daemon.ma1-mmpp-sz09.apple.com by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PFE00500ZU0UY00@ma1-mmpp-sz09.apple.com>; Fri, 21 Sep 2018 09:53:16 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-09-21_06:,, signatures=0 X-Proofpoint-Scanner-Instance: ma-grpmailp-qapp21.corp.apple.com-10000_instance1 Received: from [17.234.198.76] (unknown [17.234.198.76]) by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PFF004DH08P2160@ma1-mmpp-sz09.apple.com>; Fri, 21 Sep 2018 09:53:16 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish In-reply-to: <89954A0B46707A448411A627AD4EEE346910F6DA@SHSMSX151.ccr.corp.intel.com> Date: Fri, 21 Sep 2018 09:52:56 -0700 Cc: "Yao, Jiewen" , Samah Mansour , "Gao, Liming" , Mike Kinney , Vincent Zimmer , "lersek@redhat.com" , "Wei, David" Message-id: References: <89954A0B46707A448411A627AD4EEE346910F6DA@SHSMSX151.ccr.corp.intel.com> To: "edk2-devel@lists.01.org" X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-21_06:, , signatures=0 Subject: Re: SPI Flash Corruption X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2018 16:53:20 -0000 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable =46rom a design point of view VPD =3D=3D Vital Product Data. The idea = behind VPD was to be a place to store platform unique information = generally programmed in the factory. So things like serial number, = system UUID, mac address, etc. Usually VPD is programmed in the factory = and never updated, thus it is a good idea to put the VPD data in its own = FLASH block, and always keep that block locked. It is not uncommon for a = FLASH update utility to not update that block when the FD is updated.=20 Thanks, Andrew Fish > On Sep 21, 2018, at 2:26 AM, Wei, David wrote: >=20 > More comments: >=20 > The NV Variable region starts from 0x40000. Is there any data remains = within 0x40000 - 0x44000 region? Could you dump the flash image and = share it with us, and also file a bug in https://bugzilla.tianocore.org = as Jiewen mentioned?=20 >=20 > It occurred to me that on some old version of Minnowboard Max BIOS, = the NV variable reclaiming process would take a long time ,so that = inpatient user may think the system is stuck and cut the power. This = will break the NV variable region. And in old version of Minnowboard Max = BIOS, FTW driver is not added for PEI stage, so system may not recover = if PEI stage depends on NV variable.=20 >=20 > Newer version of Minnowboard Max BIOS re-configures SPI flash clock to = make the NV Variable reclaiming process more faster, and also adds FTW = for PEI stage. I will check which version of Minnowboard Max BIOS has = added this fix.=20 >=20 > Thanks, > David Wei >=20 > Intel SSG/STO/UEFI BIOS =20 >=20 >=20 > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of = Yao, Jiewen > Sent: Friday, September 21, 2018 7:44 AM > To: Samah Mansour > Cc: edk2-devel@lists.01.org; lersek@redhat.com > Subject: Re: [edk2] SPI Flash Corruption > Importance: High >=20 > thank you, Samah.=20 > Would you please file a tracker in edkii bugzilla ? >=20 > The term VPD might lead confusion here.=20 > Ideally VPD region is independent with UEFI variable region. It is a = special region to hold PCD with VPD type.=20 > 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.=20 >=20 > If you can add a detailed reproducing step in the bugzilla, it will be = helpful for us to understand the problem.=20 >=20 > thank you! > Yao, Jiewen >=20 >=20 >> =E5=9C=A8 2018=E5=B9=B49=E6=9C=8820=E6=97=A5=EF=BC=8C=E4=B8=8B=E5=8D=88= 11:47=EF=BC=8CSamah Mansour =E5=86=99=E9=81=93=EF= =BC=9A >>=20 >> 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. >>=20 >> Samah >>=20 >>=20 >>> On Thu, Sep 20, 2018 at 9:48 AM Laszlo Ersek = wrote: >>>=20 >>>> On 09/19/18 16:26, Samah Mansour wrote: >>>> Hello, >>>>=20 >>>>=20 >>>> 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). >>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>>=20 >>>> 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? >>>=20 >>> 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). >>>=20 >>> 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 >>>=20 >>> A Tour Beyond BIOS >>> Implementing UEFI Authenticated Variables in SMM with EDKII >>> September 2015 >>>=20 >>> 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.) >>>=20 >>> 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? >>>=20 >>> Laszlo >>>=20 >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel