From: Udit Kumar <udit.kumar@nxp.com>
To: Jeremy Linton <jeremy.linton@arm.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
Andrew Fish <afish@apple.com>,
"Olivier.Martin@arm.com" <Olivier.Martin@arm.com>,
Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
Subject: Re: Storing Non volatile variables on SD/NAND
Date: Sat, 28 Oct 2017 03:09:30 +0000 [thread overview]
Message-ID: <AM6PR0402MB33343919B1A090ACC207D905915B0@AM6PR0402MB3334.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <c5cf597d-f978-bf5f-1fc3-17b5509598ac@arm.com>
> (along those lines)
>
> 6 - Build an emulated disk controller as well as NV region in el3 (or
> el2) and export them to UEFI & the OS as real devices. Then trap/forward
> requests to the actual storage device, which is "hidden". This AFAIK was the
> basic idea behind the PS/2 emulation in x86/SMM. Again, probably not a high
> performance option.
You mean, have a driver in el3 or el2 and UEFI or OS is doing smc call to get things done.
On this line, some sort of permission manager could reside in el3 or el2.
Either UEFI or OS driver needs to make a call, if they are allowed to access this
specific controller or other driver is accessing it.
With this performance issue could be ironed out .
Regards
Udit
> -----Original Message-----
> From: Jeremy Linton [mailto:jeremy.linton@arm.com]
> Sent: Friday, October 27, 2017 11:16 PM
> To: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Udit Kumar
> <udit.kumar@nxp.com>
> Cc: edk2-devel@lists.01.org; Andrew Fish <afish@apple.com>;
> Olivier.Martin@arm.com; Vladimir Olovyannikov
> <vladimir.olovyannikov@broadcom.com>
> Subject: Re: [edk2] Storing Non volatile variables on SD/NAND
>
> On 09/20/2017 12:39 PM, Ard Biesheuvel wrote:
> > On 20 September 2017 at 10:34, Udit Kumar <udit.kumar@nxp.com> wrote:
> >>
> >> When we want to have UEFI and OS accessing same media , Possibilities
> >> I see
> >>
> >> 1- Patch OS For status check of media (diversion from generic OS), Good case
> will be modify low level driver.
> >> But we may end up some surprises on synchronization.
> >>
> >> 2- no runtime service for OS . I guess this will not be possible
> >>
> >> 3- Way the Vladimir implemented for eMMC, This has risk of losing data in
> case of AC power off.
> >>
> >> 4- update hardware with dual view (Ard suggestion)
> >>
> >
> > 5 - abstract direct block device access into a firmware service that
> > is exposed via a DXE_RUNTIME_DRIVER.
>
> (along those lines)
>
> 6 - Build an emulated disk controller as well as NV region in el3 (or
> el2) and export them to UEFI & the OS as real devices. Then trap/forward
> requests to the actual storage device, which is "hidden". This AFAIK was the
> basic idea behind the PS/2 emulation in x86/SMM. Again, probably not a high
> performance option.
>
>
> >
> > The UEFI spec allows you to expose entry points into a
> > DXE_RUNTIME_DRIVER module via a UEFI configuration table, and the OS
> > can use a driver that uses the abstracted device rather than the real
> > device. Performance is going to be terrible, probably, and lots of
> > things that are specific to SD/MMC will no longer work, but it is a
> > possibility nonetheless.
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01
> .org%2Fmailman%2Flistinfo%2Fedk2-
> devel&data=02%7C01%7Cudit.kumar%40nxp.com%7Cfe11f07ea67a4efa7d1b08
> d51d629deb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63644723
> 1755528994&sdata=FYnH3ItGhXmqxNr%2BnaJBFMcKKduf%2FcS06JEA6dT6ZQA
> %3D&reserved=0
> >
next prev parent reply other threads:[~2017-10-28 3:05 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-18 13:52 Storing Non volatile variables on SD/NAND Udit Kumar
2017-09-18 15:43 ` Ard Biesheuvel
2017-09-18 16:52 ` Vladimir Olovyannikov
2017-09-19 5:28 ` Udit Kumar
2017-09-19 16:38 ` Ard Biesheuvel
2017-09-20 4:27 ` Udit Kumar
2017-09-20 4:47 ` Andrew Fish
2017-09-20 5:09 ` Udit Kumar
2017-09-20 5:17 ` Andrew Fish
2017-09-20 14:51 ` Pankaj Bansal
2017-09-20 17:34 ` Udit Kumar
2017-09-20 17:39 ` Ard Biesheuvel
2017-09-20 17:39 ` Ard Biesheuvel
2017-09-20 17:46 ` Andrew Fish
2017-10-27 9:35 ` Udit Kumar
2017-10-27 9:37 ` Udit Kumar
2017-10-27 13:20 ` Ard Biesheuvel
2017-10-27 17:46 ` Jeremy Linton
2017-10-28 3:09 ` Udit Kumar [this message]
2017-10-30 23:10 ` Jeremy Linton
2017-10-31 4:25 ` Udit Kumar
2017-09-20 17:34 ` Andrew Fish
2017-09-18 20:47 ` Jeremy Linton
2017-09-18 20:53 ` Ard Biesheuvel
2017-09-19 5:27 ` Udit Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AM6PR0402MB33343919B1A090ACC207D905915B0@AM6PR0402MB3334.eurprd04.prod.outlook.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox