On Tue, 10 Dec 2013 10:29:34 -0800, Roy Franz wrote:
> On Tue, Dec 10, 2013 at 4:30 AM, Grant Likely wrote:
> > On Fri, 6 Dec 2013 11:20:45 -0600, Matt Sealey wrote:
> >> On Wed, Dec 4, 2013 at 4:44 PM, Matthew Garrett
> >> wrote:
> >> > On Wed, Dec 04, 2013 at 03:06:47PM -0600, Matt Sealey
On Tue, Dec 10, 2013 at 4:30 AM, Grant Likely wrote:
> On Fri, 6 Dec 2013 11:20:45 -0600, Matt Sealey wrote:
>> On Wed, Dec 4, 2013 at 4:44 PM, Matthew Garrett wrote:
>> > On Wed, Dec 04, 2013 at 03:06:47PM -0600, Matt Sealey wrote:
>> Grant suggested I should propose some patches; sure, if I'm
On Fri, 6 Dec 2013 11:20:45 -0600, Matt Sealey wrote:
> On Wed, Dec 4, 2013 at 4:44 PM, Matthew Garrett wrote:
> > On Wed, Dec 04, 2013 at 03:06:47PM -0600, Matt Sealey wrote:
> Grant suggested I should propose some patches; sure, if I'm not otherwise
> busy.
>
> Maybe the Linaro guys can
On Tue, 10 Dec 2013 10:29:34 -0800, Roy Franz roy.fr...@linaro.org wrote:
On Tue, Dec 10, 2013 at 4:30 AM, Grant Likely grant.lik...@linaro.org wrote:
On Fri, 6 Dec 2013 11:20:45 -0600, Matt Sealey n...@bakuhatsu.net wrote:
On Wed, Dec 4, 2013 at 4:44 PM, Matthew Garrett mj...@srcf.ucam.org
On Fri, 6 Dec 2013 11:20:45 -0600, Matt Sealey n...@bakuhatsu.net wrote:
On Wed, Dec 4, 2013 at 4:44 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
On Wed, Dec 04, 2013 at 03:06:47PM -0600, Matt Sealey wrote:
Grant suggested I should propose some patches; sure, if I'm not otherwise
busy.
On Tue, Dec 10, 2013 at 4:30 AM, Grant Likely grant.lik...@linaro.org wrote:
On Fri, 6 Dec 2013 11:20:45 -0600, Matt Sealey n...@bakuhatsu.net wrote:
On Wed, Dec 4, 2013 at 4:44 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
On Wed, Dec 04, 2013 at 03:06:47PM -0600, Matt Sealey wrote:
Grant
On Wed, Dec 4, 2013 at 4:44 PM, Matthew Garrett wrote:
> On Wed, Dec 04, 2013 at 03:06:47PM -0600, Matt Sealey wrote:
>
>> there's no guarantee that the kernel hasn't been decompressed over
>> some important UEFI feature or some memory hasn't been trashed. You
>> can't make that guarantee because
On Wed, Dec 4, 2013 at 4:44 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
On Wed, Dec 04, 2013 at 03:06:47PM -0600, Matt Sealey wrote:
there's no guarantee that the kernel hasn't been decompressed over
some important UEFI feature or some memory hasn't been trashed. You
can't make that
On Wed, Dec 04, 2013 at 03:06:47PM -0600, Matt Sealey wrote:
> By the time we get half-way through arm/kernel/head.S the cache and
> MMU has been turned off and on and off again by the decompressor, and
> after a large amount of guesswork and arbitrary restriction-based
> implementation, there's
On Thu, 28 Nov 2013 16:41:21 +, Leif Lindholm
wrote:
> This patch provides documentation of the [U]EFI runtime service and
> configuration features for the arm architecture.
>
> Changes since v1/v2:
> - Complete rewrite.
> - New FDT bindings.
>
> Cc: Rob Landley
> Cc:
On Wed, 4 Dec 2013 15:06:47 -0600, Matt Sealey wrote:
> If your platform has UEFI, then your platform has UEFI - if you built
> a multiplatform kernel that needs to boot on U-Boot, then you glued an
> EFI stub to it to make it boot. At some point between the stub and the
> runtime services
On Mon, 2 Dec 2013 13:51:22 -0600, Matt Sealey wrote:
> > +UEFI kernel support on ARM
> > +==
> > +UEFI kernel support on the ARM architectures (arm and arm64) is only
> > available
> > +when boot is performed through the stub.
> > +
> > +The stub populates the FDT
On Mon, 2 Dec 2013 13:51:22 -0600, Matt Sealey n...@bakuhatsu.net wrote:
+UEFI kernel support on ARM
+==
+UEFI kernel support on the ARM architectures (arm and arm64) is only
available
+when boot is performed through the stub.
+
+The stub populates the FDT
On Wed, 4 Dec 2013 15:06:47 -0600, Matt Sealey n...@bakuhatsu.net wrote:
If your platform has UEFI, then your platform has UEFI - if you built
a multiplatform kernel that needs to boot on U-Boot, then you glued an
EFI stub to it to make it boot. At some point between the stub and the
runtime
On Thu, 28 Nov 2013 16:41:21 +, Leif Lindholm leif.lindh...@linaro.org
wrote:
This patch provides documentation of the [U]EFI runtime service and
configuration features for the arm architecture.
Changes since v1/v2:
- Complete rewrite.
- New FDT bindings.
Cc: Rob Landley
On Wed, Dec 04, 2013 at 03:06:47PM -0600, Matt Sealey wrote:
By the time we get half-way through arm/kernel/head.S the cache and
MMU has been turned off and on and off again by the decompressor, and
after a large amount of guesswork and arbitrary restriction-based
implementation, there's no
On Wed, Dec 04, 2013 at 03:06:47PM -0600, Matt Sealey wrote:
> there's no guarantee that the kernel hasn't been decompressed over
> some important UEFI feature or some memory hasn't been trashed. You
> can't make that guarantee because by entering the plain zImage, you
> forfeited that
On Wed, 2013-12-04 at 15:06 -0600, Matt Sealey wrote:
> On Mon, Dec 2, 2013 at 3:07 PM, Leif Lindholm
> wrote:
> > On Mon, Dec 02, 2013 at 01:51:22PM -0600, Matt Sealey wrote:
> >> Here's where I think this whole thing falls down as being the weirdest
> >> possible implementation of this. It
On Mon, Dec 2, 2013 at 3:07 PM, Leif Lindholm wrote:
> On Mon, Dec 02, 2013 at 01:51:22PM -0600, Matt Sealey wrote:
>> Here's where I think this whole thing falls down as being the weirdest
>> possible implementation of this. It defies logic to put this
>> information in the device tree /chosen
On Mon, Dec 2, 2013 at 3:07 PM, Leif Lindholm leif.lindh...@linaro.org wrote:
On Mon, Dec 02, 2013 at 01:51:22PM -0600, Matt Sealey wrote:
Here's where I think this whole thing falls down as being the weirdest
possible implementation of this. It defies logic to put this
information in the
On Wed, 2013-12-04 at 15:06 -0600, Matt Sealey wrote:
On Mon, Dec 2, 2013 at 3:07 PM, Leif Lindholm leif.lindh...@linaro.org
wrote:
On Mon, Dec 02, 2013 at 01:51:22PM -0600, Matt Sealey wrote:
Here's where I think this whole thing falls down as being the weirdest
possible implementation
On Wed, Dec 04, 2013 at 03:06:47PM -0600, Matt Sealey wrote:
there's no guarantee that the kernel hasn't been decompressed over
some important UEFI feature or some memory hasn't been trashed. You
can't make that guarantee because by entering the plain zImage, you
forfeited that
On Mon, Dec 02, 2013 at 01:51:22PM -0600, Matt Sealey wrote:
> Here's where I think this whole thing falls down as being the weirdest
> possible implementation of this. It defies logic to put this
> information in the device tree /chosen node while also attempting to
> boot the kernel using an EFI
> +UEFI kernel support on ARM
> +==
> +UEFI kernel support on the ARM architectures (arm and arm64) is only
> available
> +when boot is performed through the stub.
> +
> +The stub populates the FDT /chosen node with (and the kernel scans for) the
> +following parameters:
>
+UEFI kernel support on ARM
+==
+UEFI kernel support on the ARM architectures (arm and arm64) is only
available
+when boot is performed through the stub.
+
+The stub populates the FDT /chosen node with (and the kernel scans for) the
+following parameters:
On Mon, Dec 02, 2013 at 01:51:22PM -0600, Matt Sealey wrote:
Here's where I think this whole thing falls down as being the weirdest
possible implementation of this. It defies logic to put this
information in the device tree /chosen node while also attempting to
boot the kernel using an EFI
This patch provides documentation of the [U]EFI runtime service and
configuration features for the arm architecture.
Changes since v1/v2:
- Complete rewrite.
- New FDT bindings.
Cc: Rob Landley
Cc: linux-...@vger.kernel.org
Signed-off-by: Leif Lindholm
---
Documentation/arm/00-INDEX |3
This patch provides documentation of the [U]EFI runtime service and
configuration features for the arm architecture.
Changes since v1/v2:
- Complete rewrite.
- New FDT bindings.
Cc: Rob Landley r...@landley.net
Cc: linux-...@vger.kernel.org
Signed-off-by: Leif Lindholm leif.lindh...@linaro.org
28 matches
Mail list logo
