From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 15DE121D046D8 for ; Mon, 18 Sep 2017 08:40:20 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id d123so1189026ith.3 for ; Mon, 18 Sep 2017 08:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MTO6Rt+j6EM7NrcwUam69DdXFmTsixyxzH0hCwsT/7Y=; b=VPB0MsfroBo1LTgvMzZG+FzRaq9m0OEgYd3IZOxj3Xr+AfK4C65Xg+gIhGhp3EXm29 FZbguoMgLgKhwvrjCfCo0medaXIa/RYvjSXeo2ja+0ISpbGNnc8v5RoV/LJ3gz0KVICl ISVbKsB+URBid0e7pqxCV1lGN65By1S1g+zkk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MTO6Rt+j6EM7NrcwUam69DdXFmTsixyxzH0hCwsT/7Y=; b=qhDy3qFSO45sTciiAVRFNUqSEIQDxLG9BNHVGK5oPlIHzdrwsTnfakOhm0HV/TSKT4 pCzJoICN+zWzEvO4pNifXgrIXuwZw7QWVanbjJnt0kYSTaYWmqU3juBn3G/9slVLLG9H VDMVyIwMjPV/YhkY3CQA7nfDK2aXH8s3LLQ6HZbrkVef5sumN5YNQrLR7ngzf+EhHHRo wiAME6iwFv+lRgNaoag/F/PUvdjnrGoG3Pph5w6XKYDNoNAAvuBsjxLLK9qw2/GKB5SW ktY8VzaNNYSSDcUNLnstMfC4vPLTQ0VSimZywKGQSoPy7xc56n8huldbJ+TFGugC0Mk8 OHVg== X-Gm-Message-State: AHPjjUjIsrfDdsM65oSfaC5xU2sQ/DGPTfXxjcbRf2brRzpTA1XazFzH 8EF/ZkZ8i7Qh+CiHxDu7A91ekWTy61IJNx13ljdR/A== X-Google-Smtp-Source: AOwi7QC7KLkbXfDU2FaCDNwDbS+LxnaVquad4tCSrvIv+Q/2/+NVshNg6ccKB6YiA7DRsFkqVVrAkzi8NOWSULdufgI= X-Received: by 10.36.36.67 with SMTP id f64mr17576637ita.10.1505749403084; Mon, 18 Sep 2017 08:43:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.152.18 with HTTP; Mon, 18 Sep 2017 08:43:22 -0700 (PDT) In-Reply-To: References: From: Ard Biesheuvel Date: Mon, 18 Sep 2017 08:43:22 -0700 Message-ID: To: Udit Kumar Cc: "edk2-devel@lists.01.org" , "grant.likely@linaro.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 15:40:20 -0000 Content-Type: text/plain; charset="UTF-8" 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.