From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 EEB8621D046D7 for ; Mon, 18 Sep 2017 09:49:06 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id w22so762330ywa.13 for ; Mon, 18 Sep 2017 09:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=kshQ0TzjB5HPfsCOJxSgsrM4aJ11BuFq4XZMO6by20w=; b=LHciwUQ986idKj+a/F0S85xIjsOMeeobqaZieGeyQPJKVY3U+x8mOvGWvBhkXnhT5l oS5pbEShxEozU8T5ylUtf9y8h1DHA8FBS4p1mOIoWAIJYOesMWd1+bph0QlDRAcipMm1 ENuoX8H+zPQJi82IvI/rmVObgdYu8Xm0wtPAQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=kshQ0TzjB5HPfsCOJxSgsrM4aJ11BuFq4XZMO6by20w=; b=Q5647AfIubsqYwTMXWMceG+9o+FKrka6N/CY5XsElpy3YvVch6qiff9wNhC7Zn4iN+ 08SJndIJtbDfPqHXqlNQRbMbYCk8r1h907WQ9QlBojPXBW5WoiIZapFrhq3kbNYvaKzd DN+cRCJE4Y1lU0TDCXBIcZw/JXuTpKdc/TBzdRrLUy0r27o2Kpto6tsV3E1mnevtJPiN P0fVtK9vwQBenci2kIVPcRHqCFveadLUgnqtKcHa0bvSS+W4fsKXq2SJ8XNqNk/VBsDw q1KCIOVdNEeBiZ7rRemEa/eo8gZTtlN5PStpc+fFv6PWCo3KNyZGS2fE2MrtI/Bd7mEU ar4w== X-Gm-Message-State: AHPjjUjR2JA/8UvXjnTl9euWSngf5fGGvpylXyHQF6d/rQoyTf/WbrhM N2sP8piZXLEE/2QpPcEBSbp022Rh7UPNI/AbI6Yz+A== X-Google-Smtp-Source: ADKCNb5/H+Gk55SSmaDQ+8u+GIBEJQX1Dj7RyBRuw4sf65vUYIiXAceMDl7KQ66Hyc2zar5UQDjMnJP/QcbIPGJzJFM= X-Received: by 10.37.230.71 with SMTP id d68mr28440746ybh.345.1505753529561; Mon, 18 Sep 2017 09:52:09 -0700 (PDT) From: Vladimir Olovyannikov References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIbXpgZwtm62qMRdZOe9w14kELjagFZOK1uoh+tfFA= Date: Mon, 18 Sep 2017 09:52:08 -0700 Message-ID: To: Ard Biesheuvel , Udit Kumar Cc: grant.likely@linaro.org, edk2-devel@lists.01.org, Olivier.Martin@arm.com Subject: Re: Storing Non volatile variables on SD/NAND X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 16:49:07 -0000 Content-Type: text/plain; charset="UTF-8" > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of > Ard Biesheuvel > Sent: Monday, September 18, 2017 8:43 AM > To: Udit Kumar > Cc: grant.likely@linaro.org.; edk2-devel@lists.01.org; > Olivier.Martin@arm.com > Subject: Re: [edk2] Storing Non volatile variables on SD/NAND > > On 18 September 2017 at 06:52, Udit Kumar wrote: > > Hi EDK-2 Experts, > > I am looking to store NV variables on SD/NAND device. > > > > While browsing, I came across some old post at link, > > http://feishare.com/efimail/messages/20130319-1700- > Re__edk2__Regarding > > _storing_Boot_Device_Config_in_persistent_memory-Olivier_Martin.html > > > > Looks like, this is possible easily. > > That's a bold statement dude :-) > > >>> What you need to support Non-Volatile UEFI variables is a Non-Volatile > Memory. And also a driver that implements the EFI Firmware Volume Block > protocol for this NVM device. > > > > But MdeModulePkg does Copymem from NV variable start memory to > some > > allocated buffers. With SD/NAND Copymem is not possible, Is this > > something changes since 2013 or there are some other way to use > > SD/NAND > > > > No, SD/MMC cannot currently be used as the backing store for the EFI > variable store. The problem is that the variable protocols are architectural > protocols in PI that need to be present before any driver model drivers are > dispatched, and so putting the variable store on block devices is not > something that the PI software architecture currently supports (unless you > reimplement the whole driver stack as DXE drivers). > > On top of that, it is almost impossible to share a block device that sits behind > a controller between the firmware and the OS at runtime (i.e., for > SetVariable() calls made by efibootmgr under Linux), because only a single > agent can take ownership of the controller at any given time. (You /could/ > dedicate the SD/MMC to the firmware entirely, and boot from SATA or USB, > but this is out of the question on most platforms that need to use SD/MMC > for that variable backing store, i.e., mobile platforms) > > The best thing would be for you to convince the hardware architects in your > company to design and implement dual-ported SD/MMC controllers that > allow a single SD/MMC to have two logical views that are independent > (although I'm unsure if that is even possible in the context of the SD/MMC > specifications) > > Thanks, > Ard. Udit, Ard is absolutely right. Following design I had to implement variable store on the EMMC boot partition 1 (not exactly SD card, but close; the same is applied to NAND I guess). To do that I forked VariableRuntime driver and changed it to do cache writes into the store (just modifying store memory) at runtime. This is because you cannot share eMMC store between OS (Linux) and the UEFI service at the same time, and you cannot predict when OS writes/reads to/from the EMMC device. So I do cache writes at runtime (just modifying store in memory), and flush the store on reboot/shutdown. For this purpose my ResetSystemLib calls into the Variable service and forces flush. Variable service reinitiates eMMC controller and really writes into the store on the eMMC. Real flush is also performed on ExitBootServices(). As a big drawback an OS should either reset or shutdown (get into UEFI ResetSystemLib) in order for variable store to be updated physically; Physical flush is also forced on ExitBootServices - be it a reset command, or booting an OS. Just pressing a reset button (example: Linux Kernel panic with no reset) would cause variable changes for this session to get lost. Thank you, Vladimir > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel