From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-in24.apple.com (mail-out24.apple.com [17.171.2.34]) (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 C5DD321D492C1 for ; Tue, 19 Sep 2017 21:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1505882865; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tCZvfWotaPT+0fd4QVfqsTBAp0JT4irTGwt6rS0xv0c=; b=wo75iBkRmbGXqsnkCIddu0iOlJHRKYKWG34rU1bcQfmjwaXs2lNwXGSfzVM9+R3e ibfNqUloD4soxJaKpmRNoqHBXpN0Z3Pkuqz0lRmuKBwAoj7LT9a34ncloJ7rnGGb SdEThkI8V1XDrVD3+oriA782scVIUxSUBaZWdPWaUykctNmBjmT14y8nmycZuxOJ n5Pp3TQDGihf8lMJk/ruekQD/vYkY4iP+TwtGfaL8HOdPWXj7vyYvq3QHbv5yYrG bnitfvDbJSdY6aYd/Q5JxDObk4To4BOiDwj26siilFwuGEGe0quckCg0wCIK8sEd NcW7jUepQfWYetBr9PIl0g==; Received: from relay26.apple.com (relay26.apple.com [17.171.128.107]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in24.apple.com (Apple Secure Mail Relay) with SMTP id CA.AB.25405.1F2F1C95; Tue, 19 Sep 2017 21:47:45 -0700 (PDT) X-AuditID: 11ab0218-27bff7000000633d-af-59c1f2f10483 Received: from ma1-mmpp-sz07.apple.com (ma1-mmpp-sz07.apple.com [17.171.128.149]) by relay26.apple.com (Apple SCV relay) with SMTP id 3A.7E.30418.1F2F1C95; Tue, 19 Sep 2017 21:47:45 -0700 (PDT) MIME-version: 1.0 Received: from [17.234.248.165] by ma1-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OWK00MHWANI3G00@ma1-mmpp-sz07.apple.com>; Tue, 19 Sep 2017 21:47:45 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish In-reply-to: Date: Tue, 19 Sep 2017 21:47:40 -0700 Cc: Ard Biesheuvel , "edk2-devel@lists.01.org" , Vladimir Olovyannikov , "Olivier.Martin@arm.com" Message-id: References: To: Udit Kumar X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUiuLohW/fjp4ORBitfiVj8/7Cb0WLPoaPM FkfXfWG3WLHkEJvF+8XHmR1YPdbMW8PoMev+WTaPO9f2sHl0z/7H4rHx3Q6mANYoLpuU1JzM stQifbsErowdGz4zFawWr9hy9zprA+NOoS5GDg4JAROJT1siuxi5OIQE1jNJvJ59nKWLkRMs vuPAOhaIxGFGibtdb1hBErwCghI/Jt9jAWlmFpCXOHheFiTMLKAl8f1RK1T9N0aJ4w0dzCAJ YQFxiXdnNkHZthI/tvSALWATUJZYMf8DO4jNKZAscW7PfrD5LAKqEt1Nk8AGMQvcYJR4sesz G8RiG4mN004zQWy4xCyx/Ms7sIQI0KTbDVOYIc6Wlbg1+xIzSJGEwBo2iXfz7rNNYBSeheTy WQiXz0Jy+QJG5lWMwrmJmTm6mXlGJnqJBQU5qXrJ+bmbGMGxwSSxg/HLa8NDjAIcjEo8vAFW ByOFWBPLiitzDzFKc7AoifM6zQAKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYKytOPS6QMht +kFZHTXLgD+vFovt4Wf+vVLvRNKRsFhRjW39pvPa5WpSi+Mffr6YZfW11Ftc0mL5P43C2Nt7 n/12OLlJWqTyz8mNH0pmldkdOFv6qn3D/mUHTDub+T+KMm5J6Gv0K+Q95yjwjunSygDJTwYn yzT+Llm/vPSWhb/79P2/H8quOKXEUpyRaKjFXFScCABh1w1abgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUiuLphqu7HTwcjDbr7+C3+f9jNaLHn0FFm i6PrvrBbrFhyiM3i/eLjzA6sHmvmrWH0mHX/LJvHnWt72Dy6Z/9j8dj4bgdTAGsUl01Kak5m WWqRvl0CV8aODZ+ZClaLV2y5e521gXGnUBcjJ4eEgInEjgPrWLoYuTiEBA4zStztesMKkuAV EJT4MfkeUIKDg1lAXuLgeVmQMLOAlsT3R61Q9d8YJY43dDCDJIQFxCXendkEZdtK/NjSwwJi swkoS6yY/4EdxOYUSJY4t2c/2HwWAVWJ7qZJYIOYBW4wSrzY9ZkNYrGNxMZpp5kgNlxillj+ 5R1YQgRo0u2GKcwQZ8tK3Jp9iXkCo8AsJMfOQjh2FpJjFzAyr2IULErNSaw0MtNLLCjISdVL zs/dxAgJ5uwdjCfvmR1iFOBgVOLhXWFzMFKINbGsuDL3EKMEB7OSCK/aR6AQb0piZVVqUX58 UWlOavEhRmkOFiVxXpGZQCmB9MSS1OzU1ILUIpgsEwenVANj4/wl/z5Fyb2vjfd6sjN3WvsD C71+njcrBVxztiwOjTRodug+yLjM90/yOQU5Ky2Jhfvr268+mDnrYvuhmnn7Xs3Vr8nqeCLI HfzCvfdpCpdK4DvR0oRZUTrP3f9G7Ds7rbl+5sFVP204pNyFl3zfmJ7S1LCq3XTluYlCP/KZ mtNOSjR9XeSmxFKckWioxVxUnAgAjGwiNWICAAA= 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: Wed, 20 Sep 2017 04:44:41 -0000 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII > On Sep 19, 2017, at 9:27 PM, Udit Kumar wrote: > > >> On 18 September 2017 at 22:28, Udit Kumar wrote: >>> Thanks Vladimir, >>> With your design, you did delayed write to eMMC due to sharing with >>> OS. But it works for you:) Say if eMMC controllers offers you a >>> status bit, if eMMC storage is being used for not. Then this could be possible to >> update at run time, both OS/UEFI needs to check and wait if controller is being >> used. >> >> That is the problem right there. The nice thing about a firmware spec is that you >> don't have to care about how it was implemented if you adhere to the API rules. > > Yup, we are fine as long as long UEFI firmware is stored on dedicated media. > >> Imposing additional restrictions (such as requiring the OS to be careful about not >> using the eMMC when it may be in use by the firmware) defeats the purpose of >> using UEFI, since you won't be able to use a generic OS anyway. >> > > Hmm, so far, I haven't come across where UEFI specs says, we need a separate > Storage for firmware. (May be I missed some part of specs) > Irrespective of storage media, we have this problem if OS and UEFI shares same > storage. > Udit, Can you point out the spec that states you can't boot Linux and Windows at the same time on a PC? :) When you write a spec it is not practical do document what is not possible, you can only document the API the rest is implied by the implementation. So for example the UEFI spec does not document why the firmware and OS can't share a hardware device, just like you can't have 2 operating systems running on bare metal at the same time. It is a little like Occam's Razor the reason that the firmware and the OS can not share a hardware device is the mechanics of how to share a hardware device is not defined in the spec, thus it is not part of the API and not possible. Thanks, Andrew Fish >>> For sure, some synchronization issues need to be ironed out (or maybe I am >> just dreaming here). >>> >>> On part 2) where you forked VariableRuntime driver , could we think of >>> updating VariableRuntime driver, to support non-XIP or memory mapped >> devices. >>> >> >> I think being able to support non-memorymapped FV volumes for the variable >> store would be a big improvement. This does require changes to both the >> FaultTolerantWrite drivers and the VariableRuntime drivers, which both appear >> in PEI, DXE and SMM flavors, and require thorough review due to the security >> impact bugs have in this layer, so this is a rather large chunk of work to take on. > > Thanks, your list is longer than what I was thinking :-) > I think, for embedded world with UEFI, later or sooner, this will be required. > > Thanks > Udit > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel