From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4864:20::d33; helo=mail-io1-xd33.google.com; envelope-from=samah.mansour1@gmail.com; receiver=edk2-devel@lists.01.org Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id D4E5A211350CA for ; Thu, 20 Sep 2018 08:47:13 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id c22-v6so7797627iob.1 for ; Thu, 20 Sep 2018 08:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qYSVnJvirkiaQ2pJCxuiRqYPauPOv0EOMPEqvWGC4Gs=; b=brvR6KSLKtvu2iaBQda3pieAgbRKM3sjIvyzhiq2+Leuw6HvAZ+FigSSf2yfxnHSrp aF4DwdUkA+HZ3KuNqlojfyiw7APVuAIsDDse1334pdWBpMT5JdGY3vGLQJbAswsatFwW vgISGcBPsEUamMecj21afl7p57aWxGLscg5uKH35qXIzyGEEOIqgv+UWfScwEZdC1H4m EYb3F3ChQLr7hYX22gp5qlcRDDEYe/Sf1mAdMDbAP3x8cBWYb1PAUwh/ydOOiYsk2HDR H/QPpRnYrzEbCQfauKbwukEk7U7kwgRCjzlnRrhcdf/BoE/FPBCTbUr/4+y5GBDyPIqJ syww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qYSVnJvirkiaQ2pJCxuiRqYPauPOv0EOMPEqvWGC4Gs=; b=fXANGMcQVdeXK+u+AqSbqh3H6ApzlGo/z+RYGvMl6tQQMYIy6+U+miUk/+g38u+PUA X2oOVkyjZKnpTDljg3QiNqt6/IZgoAExXUHzx5ty96OonOS5RIjH72KxMuvNbtC7ZjE+ IjPKyUVUF4JbP664frTmC9NBQ8ZmzBkSlQPNDtWdGg2E59OP4D6/BEM28dWy4OgTiGlN kSc2y0gs5Ph0mvscGbygFGZRa8QJwlXKFTDNxWAn9WMFUCpiJHukMVW/iNA5W5Uo8IBA OeDPvoxTJfywvIFqXx4AWVLM+SXN7hP/WYD02hLslsouFWeANcJ+qjIvK94nJsQLna6w D3Tg== X-Gm-Message-State: APzg51A1sqN2/fObXxJhOJpgOKHrTMBAVHr6u7CmyzoGopqdAL6NIIlC ONOCyLnAr7up+eHdbiaAgGn0VITHFigggxPIx5rZ13+z X-Google-Smtp-Source: ANB0VdaB19Zv6ciMvQRvs4b02nTlJ2OZtfu2uAbuj9vwfRHME7N8moiDfkK33ERG4bVCVIuNX4lcIXWI+LjTRAyBCj8= X-Received: by 2002:a6b:38d6:: with SMTP id f205-v6mr34002629ioa.305.1537458432938; Thu, 20 Sep 2018 08:47:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Samah Mansour Date: Thu, 20 Sep 2018 11:47:01 -0400 Message-ID: To: lersek@redhat.com Cc: edk2-devel@lists.01.org X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Thu, 20 Sep 2018 15:47:14 -0000 Content-Type: text/plain; charset="UTF-8" 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 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 >