On 06/25/2013 01:11:00 PM, Leif Lindholm wrote:
This patch provides documentation of the [U]EFI runtime services and
configuration features.
Signed-off-by: Leif Lindholm
---
Documentation/arm/00-INDEX |3 +++
Documentation/arm/uefi.txt | 39
+++
2
On 06/25/2013 01:11:00 PM, Leif Lindholm wrote:
This patch provides documentation of the [U]EFI runtime services and
configuration features.
Signed-off-by: Leif Lindholm leif.lindh...@linaro.org
---
Documentation/arm/00-INDEX |3 +++
Documentation/arm/uefi.txt | 39
On Thu, Jun 27, 2013 at 7:04 PM, Stephen Warren wrote:
> On 06/26/2013 01:31 PM, Leif Lindholm wrote:
>> On Wed, Jun 26, 2013 at 12:32:30PM -0600, Stephen Warren wrote:
> What about ARMv8? Is the intention to have a separate definition for the
> UEFI bindings on ARMv8, so that
On 06/26/2013 07:38 AM, James Bottomley wrote:
> On Wed, 2013-06-26 at 14:59 +0100, Matt Fleming wrote:
>> On Wed, 26 Jun, at 03:53:11PM, Leif Lindholm wrote:
>>> It's completely feasible, but we'd need to use a different method to do
>>> the boot services call with a 1:1 mapping (idmap support is
On Thu, Jun 27, 2013 at 08:04:46AM -0700, James Bottomley wrote:
> That's what the x86_64 proposal from Borislav Petkov does. We alter the
> page tables before calling into the UEFI hooks to make sure both the
> physical and virtual addresses work. Your problem on ARM with this
> approach is
On 06/26/2013 01:31 PM, Leif Lindholm wrote:
> On Wed, Jun 26, 2013 at 12:32:30PM -0600, Stephen Warren wrote:
What about ARMv8? Is the intention to have a separate definition for the
UEFI bindings on ARMv8, so that compatibility isn't an issue? What if a
future version of UEFI
On Thu, Jun 27, 2013 at 08:09:50AM -0700, James Bottomley wrote:
> On Thu, 2013-06-27 at 15:37 +0100, Matthew Garrett wrote:
> > And yet it's the only mode in which the firmrware is actually tested
> > against an OS, so we don't have any real choice in the matter.
>
> Agree for x86 ... we just
On Thu, Jun 27, 2013 at 4:09 PM, James Bottomley
wrote:
> On Thu, 2013-06-27 at 15:37 +0100, Matthew Garrett wrote:
>> On Wed, Jun 26, 2013 at 11:33:41PM -0700, James Bottomley wrote:
>> > On Thu, 2013-06-27 at 07:23 +0100, Grant Likely wrote:
>> > > What is the problem trying to be avoided by
On Thu, 2013-06-27 at 15:54 +0100, Grant Likely wrote:
> On Thu, Jun 27, 2013 at 7:33 AM, James Bottomley
> wrote:
> > On Thu, 2013-06-27 at 07:23 +0100, Grant Likely wrote:
> >> On Thu, Jun 27, 2013 at 2:32 AM, Matthew Garrett
> >> wrote:
> >> > On Wed, Jun 26, 2013 at 07:38:19AM -0700, James
On Thu, 2013-06-27 at 15:37 +0100, Matthew Garrett wrote:
> On Wed, Jun 26, 2013 at 11:33:41PM -0700, James Bottomley wrote:
> > On Thu, 2013-06-27 at 07:23 +0100, Grant Likely wrote:
> > > What is the problem trying to be avoided by not using the virtual map?
> > > Is it passing the virtual
On Thu, Jun 27, 2013 at 7:33 AM, James Bottomley
wrote:
> On Thu, 2013-06-27 at 07:23 +0100, Grant Likely wrote:
>> On Thu, Jun 27, 2013 at 2:32 AM, Matthew Garrett wrote:
>> > On Wed, Jun 26, 2013 at 07:38:19AM -0700, James Bottomley wrote:
>> >> The fixed virtual address scheme currently being
On Thu, Jun 27, 2013 at 11:00:50AM +0200, Leif Lindholm wrote:
> On Thu, Jun 27, 2013 at 02:32:19AM +0100, Matthew Garrett wrote:
> > We can probably get away with that now, but it does risk us ending up
> > with some firmware that expects to run in physical mode (boards designed
> > for Linux)
On Wed, Jun 26, 2013 at 11:33:41PM -0700, James Bottomley wrote:
> On Thu, 2013-06-27 at 07:23 +0100, Grant Likely wrote:
> > What is the problem trying to be avoided by not using the virtual map?
> > Is it passing the virtual mapping data from one kernel to the next
> > when kexecing? Or
On Wednesday 26 June 2013, Grant Likely wrote:
> > index 000..5c48271
> > --- /dev/null
> > +++ b/Documentation/arm/uefi.txt
> > @@ -0,0 +1,39 @@
> > +The nomenclature EFI and UEFI are used interchangeably in this document.
> > +
> > +The implementation depends on receiving pointers to the
On Thu, Jun 27, 2013 at 02:32:19AM +0100, Matthew Garrett wrote:
> On Wed, Jun 26, 2013 at 07:38:19AM -0700, James Bottomley wrote:
> > The fixed virtual address scheme currently being looked at for x86_64 to
> > make SetVirtualAddressMap() kexec invariant doesn't work on 32 bit
> > because the
On Thu, 2013-06-27 at 07:23 +0100, Grant Likely wrote:
> On Thu, Jun 27, 2013 at 2:32 AM, Matthew Garrett wrote:
> > On Wed, Jun 26, 2013 at 07:38:19AM -0700, James Bottomley wrote:
> >> The fixed virtual address scheme currently being looked at for x86_64 to
> >> make SetVirtualAddressMap()
On Thu, Jun 27, 2013 at 2:32 AM, Matthew Garrett wrote:
> On Wed, Jun 26, 2013 at 07:38:19AM -0700, James Bottomley wrote:
>> The fixed virtual address scheme currently being looked at for x86_64 to
>> make SetVirtualAddressMap() kexec invariant doesn't work on 32 bit
>> because the address space
On Thu, Jun 27, 2013 at 2:32 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
On Wed, Jun 26, 2013 at 07:38:19AM -0700, James Bottomley wrote:
The fixed virtual address scheme currently being looked at for x86_64 to
make SetVirtualAddressMap() kexec invariant doesn't work on 32 bit
because the
On Thu, 2013-06-27 at 07:23 +0100, Grant Likely wrote:
On Thu, Jun 27, 2013 at 2:32 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
On Wed, Jun 26, 2013 at 07:38:19AM -0700, James Bottomley wrote:
The fixed virtual address scheme currently being looked at for x86_64 to
make
On Thu, Jun 27, 2013 at 02:32:19AM +0100, Matthew Garrett wrote:
On Wed, Jun 26, 2013 at 07:38:19AM -0700, James Bottomley wrote:
The fixed virtual address scheme currently being looked at for x86_64 to
make SetVirtualAddressMap() kexec invariant doesn't work on 32 bit
because the address
On Wednesday 26 June 2013, Grant Likely wrote:
index 000..5c48271
--- /dev/null
+++ b/Documentation/arm/uefi.txt
@@ -0,0 +1,39 @@
+The nomenclature EFI and UEFI are used interchangeably in this document.
+
+The implementation depends on receiving pointers to the UEFI memory map
On Wed, Jun 26, 2013 at 11:33:41PM -0700, James Bottomley wrote:
On Thu, 2013-06-27 at 07:23 +0100, Grant Likely wrote:
What is the problem trying to be avoided by not using the virtual map?
Is it passing the virtual mapping data from one kernel to the next
when kexecing? Or something else?
On Thu, Jun 27, 2013 at 11:00:50AM +0200, Leif Lindholm wrote:
On Thu, Jun 27, 2013 at 02:32:19AM +0100, Matthew Garrett wrote:
We can probably get away with that now, but it does risk us ending up
with some firmware that expects to run in physical mode (boards designed
for Linux) and
On Thu, Jun 27, 2013 at 7:33 AM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
On Thu, 2013-06-27 at 07:23 +0100, Grant Likely wrote:
On Thu, Jun 27, 2013 at 2:32 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
On Wed, Jun 26, 2013 at 07:38:19AM -0700, James Bottomley wrote:
On Thu, 2013-06-27 at 15:37 +0100, Matthew Garrett wrote:
On Wed, Jun 26, 2013 at 11:33:41PM -0700, James Bottomley wrote:
On Thu, 2013-06-27 at 07:23 +0100, Grant Likely wrote:
What is the problem trying to be avoided by not using the virtual map?
Is it passing the virtual mapping data
On Thu, 2013-06-27 at 15:54 +0100, Grant Likely wrote:
On Thu, Jun 27, 2013 at 7:33 AM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
On Thu, 2013-06-27 at 07:23 +0100, Grant Likely wrote:
On Thu, Jun 27, 2013 at 2:32 AM, Matthew Garrett mj...@srcf.ucam.org
wrote:
On
On Thu, Jun 27, 2013 at 4:09 PM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
On Thu, 2013-06-27 at 15:37 +0100, Matthew Garrett wrote:
On Wed, Jun 26, 2013 at 11:33:41PM -0700, James Bottomley wrote:
On Thu, 2013-06-27 at 07:23 +0100, Grant Likely wrote:
What is the problem
On Thu, Jun 27, 2013 at 08:09:50AM -0700, James Bottomley wrote:
On Thu, 2013-06-27 at 15:37 +0100, Matthew Garrett wrote:
And yet it's the only mode in which the firmrware is actually tested
against an OS, so we don't have any real choice in the matter.
Agree for x86 ... we just have to
On 06/26/2013 01:31 PM, Leif Lindholm wrote:
On Wed, Jun 26, 2013 at 12:32:30PM -0600, Stephen Warren wrote:
What about ARMv8? Is the intention to have a separate definition for the
UEFI bindings on ARMv8, so that compatibility isn't an issue? What if a
future version of UEFI allows LPAE
On Thu, Jun 27, 2013 at 08:04:46AM -0700, James Bottomley wrote:
That's what the x86_64 proposal from Borislav Petkov does. We alter the
page tables before calling into the UEFI hooks to make sure both the
physical and virtual addresses work. Your problem on ARM with this
approach is that
On 06/26/2013 07:38 AM, James Bottomley wrote:
On Wed, 2013-06-26 at 14:59 +0100, Matt Fleming wrote:
On Wed, 26 Jun, at 03:53:11PM, Leif Lindholm wrote:
It's completely feasible, but we'd need to use a different method to do
the boot services call with a 1:1 mapping (idmap support is not
On Thu, Jun 27, 2013 at 7:04 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 06/26/2013 01:31 PM, Leif Lindholm wrote:
On Wed, Jun 26, 2013 at 12:32:30PM -0600, Stephen Warren wrote:
What about ARMv8? Is the intention to have a separate definition for the
UEFI bindings on ARMv8, so that
On Wed, Jun 26, 2013 at 07:38:19AM -0700, James Bottomley wrote:
> The fixed virtual address scheme currently being looked at for x86_64 to
> make SetVirtualAddressMap() kexec invariant doesn't work on 32 bit
> because the address space isn't big enough. For ARM, given that we've
> much more
On Wed, Jun 26, 2013 at 12:32:30PM -0600, Stephen Warren wrote:
> >> What about ARMv8? Is the intention to have a separate definition for the
> >> UEFI bindings on ARMv8, so that compatibility isn't an issue? What if a
> >> future version of UEFI allows LPAE usage?
> >
> > It is unlikely that
On 06/26/2013 07:20 AM, Grant Likely wrote:
> On Wed, Jun 26, 2013 at 12:42 AM, Stephen Warren
> wrote:
>> On 06/25/2013 12:11 PM, Leif Lindholm wrote:
>>> This patch provides documentation of the [U]EFI runtime services and
>>> configuration features.
>>
>>
>>> diff --git
On Wed, 2013-06-26 at 14:59 +0100, Matt Fleming wrote:
> On Wed, 26 Jun, at 03:53:11PM, Leif Lindholm wrote:
> > It's completely feasible, but we'd need to use a different method to do
> > the boot services call with a 1:1 mapping (idmap support is not available
> > until much later in the boot
On Wed, Jun 26, 2013 at 3:04 PM, Leif Lindholm wrote:
> On Wed, Jun 26, 2013 at 02:13:39PM +0100, Grant Likely wrote:
>> > +- 'efi-runtime-mmap':
>> > + Physical address of an EFI memory map, containing at least
>> > + the regions to be preserved. (required)
>> > +- 'efi-runtime-mmap-size':
>>
On Wed, Jun 26, 2013 at 02:13:39PM +0100, Grant Likely wrote:
> > diff --git a/Documentation/arm/uefi.txt b/Documentation/arm/uefi.txt
> > +It (early) parses the FDT for the following parameters:
>
> Need to state which node these properties can be found in. I recommend /chosen
Will do.
> I
On Wed, Jun 26, 2013 at 02:20:23PM +0100, Grant Likely wrote:
> On Wed, Jun 26, 2013 at 12:42 AM, Stephen Warren
> wrote:
> > the properties) should be part of a file in
> > Documentation/devicetree/bindings/ (arm/uefi.txt?).
> >
> > What node are these properties expected to be contained
On Wed, 26 Jun, at 03:53:11PM, Leif Lindholm wrote:
> It's completely feasible, but we'd need to use a different method to do
> the boot services call with a 1:1 mapping (idmap support is not available
> until much later in the boot process).
At least if you no longer relied upon the idmap we
On Wed, Jun 26, 2013 at 12:42 AM, Stephen Warren wrote:
> On 06/25/2013 12:11 PM, Leif Lindholm wrote:
>> This patch provides documentation of the [U]EFI runtime services and
>> configuration features.
>
>
>> diff --git a/Documentation/arm/uefi.txt b/Documentation/arm/uefi.txt
>
>> +The
On Tue, Jun 25, 2013 at 7:11 PM, Leif Lindholm wrote:
> This patch provides documentation of the [U]EFI runtime services and
> configuration features.
>
> Signed-off-by: Leif Lindholm
> ---
> Documentation/arm/00-INDEX |3 +++
> Documentation/arm/uefi.txt | 39
On Tue, Jun 25, 2013 at 7:11 PM, Leif Lindholm leif.lindh...@linaro.org wrote:
This patch provides documentation of the [U]EFI runtime services and
configuration features.
Signed-off-by: Leif Lindholm leif.lindh...@linaro.org
---
Documentation/arm/00-INDEX |3 +++
On Wed, Jun 26, 2013 at 12:42 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 06/25/2013 12:11 PM, Leif Lindholm wrote:
This patch provides documentation of the [U]EFI runtime services and
configuration features.
diff --git a/Documentation/arm/uefi.txt b/Documentation/arm/uefi.txt
+The
On Wed, 26 Jun, at 03:53:11PM, Leif Lindholm wrote:
It's completely feasible, but we'd need to use a different method to do
the boot services call with a 1:1 mapping (idmap support is not available
until much later in the boot process).
At least if you no longer relied upon the idmap we could
On Wed, Jun 26, 2013 at 02:20:23PM +0100, Grant Likely wrote:
On Wed, Jun 26, 2013 at 12:42 AM, Stephen Warren swar...@wwwdotorg.org
wrote:
the properties) should be part of a file in
Documentation/devicetree/bindings/ (arm/uefi.txt?).
What node are these properties expected to be
On Wed, Jun 26, 2013 at 02:13:39PM +0100, Grant Likely wrote:
diff --git a/Documentation/arm/uefi.txt b/Documentation/arm/uefi.txt
+It (early) parses the FDT for the following parameters:
Need to state which node these properties can be found in. I recommend /chosen
Will do.
I would
On Wed, Jun 26, 2013 at 3:04 PM, Leif Lindholm leif.lindh...@linaro.org wrote:
On Wed, Jun 26, 2013 at 02:13:39PM +0100, Grant Likely wrote:
+- 'efi-runtime-mmap':
+ Physical address of an EFI memory map, containing at least
+ the regions to be preserved. (required)
+-
On Wed, 2013-06-26 at 14:59 +0100, Matt Fleming wrote:
On Wed, 26 Jun, at 03:53:11PM, Leif Lindholm wrote:
It's completely feasible, but we'd need to use a different method to do
the boot services call with a 1:1 mapping (idmap support is not available
until much later in the boot process).
On 06/26/2013 07:20 AM, Grant Likely wrote:
On Wed, Jun 26, 2013 at 12:42 AM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 06/25/2013 12:11 PM, Leif Lindholm wrote:
This patch provides documentation of the [U]EFI runtime services and
configuration features.
diff --git
On Wed, Jun 26, 2013 at 12:32:30PM -0600, Stephen Warren wrote:
What about ARMv8? Is the intention to have a separate definition for the
UEFI bindings on ARMv8, so that compatibility isn't an issue? What if a
future version of UEFI allows LPAE usage?
It is unlikely that will happen on
On Wed, Jun 26, 2013 at 07:38:19AM -0700, James Bottomley wrote:
The fixed virtual address scheme currently being looked at for x86_64 to
make SetVirtualAddressMap() kexec invariant doesn't work on 32 bit
because the address space isn't big enough. For ARM, given that we've
much more
On 06/25/2013 12:11 PM, Leif Lindholm wrote:
> This patch provides documentation of the [U]EFI runtime services and
> configuration features.
> diff --git a/Documentation/arm/uefi.txt b/Documentation/arm/uefi.txt
> +The implementation depends on receiving pointers to the UEFI memory map
> +and
On 06/25/2013 02:11 PM, Leif Lindholm wrote:
> This patch provides documentation of the [U]EFI runtime services and
> configuration features.
>
> Signed-off-by: Leif Lindholm
> ---
> Documentation/arm/00-INDEX |3 +++
> Documentation/arm/uefi.txt | 39
This patch provides documentation of the [U]EFI runtime services and
configuration features.
Signed-off-by: Leif Lindholm
---
Documentation/arm/00-INDEX |3 +++
Documentation/arm/uefi.txt | 39 +++
2 files changed, 42 insertions(+)
create mode 100644
This patch provides documentation of the [U]EFI runtime services and
configuration features.
Signed-off-by: Leif Lindholm leif.lindh...@linaro.org
---
Documentation/arm/00-INDEX |3 +++
Documentation/arm/uefi.txt | 39 +++
2 files changed, 42
On 06/25/2013 02:11 PM, Leif Lindholm wrote:
This patch provides documentation of the [U]EFI runtime services and
configuration features.
Signed-off-by: Leif Lindholm leif.lindh...@linaro.org
---
Documentation/arm/00-INDEX |3 +++
Documentation/arm/uefi.txt | 39
On 06/25/2013 12:11 PM, Leif Lindholm wrote:
This patch provides documentation of the [U]EFI runtime services and
configuration features.
diff --git a/Documentation/arm/uefi.txt b/Documentation/arm/uefi.txt
+The implementation depends on receiving pointers to the UEFI memory map
+and
58 matches
Mail list logo
