On 11/29/2013 11:44 AM, Matthew Garrett wrote:
> UEFI time services are often broken once we're in virtual mode. We were
> already refusing to use them on 64-bit systems, but it turns out that
> they're also broken on some 32-bit firmware, including the Dell Venue.
> Disable them for now, we can re
On Sat, Nov 30, 2013 at 06:04:07AM +0800, joeyli wrote:
> I am sure his patchset can walkaround physical address accessing issue
> on a broken 64-bit machine. But, I didn't test it on 32-bit issue
> machine.
Yeah, my patches don't change 32-bit so I wouldn't expect any
difference, unfortunately.
This patch adds PE/COFF header fields to the start of the Image
so that it appears as an EFI application to EFI firmware. An EFI
stub is included to allow direct booting of the kernel Image. Due
to EFI firmware limitations, only little endian kernels with 4K
page sizes are supported at this time. S
This patch adds EFI runtime support for arm64. The runtime support allows the
kernel to access various EFI runtime services provided by EFI firmware. Things
like reboot, real time clock, EFI boot variables, and others.
Signed-off-by: Mark Salter
CC: Catalin Marinas
CC: Will Deacon
CC: linux-arm
This patch series adds EFI support to the arm64 kernel. This support has
two main parts: an EFI stub and runtime support. The EFI stub support
has the kernel masquerade as a PE/COFF application which can be directly
booted by EFI firmware (or by secondary loaders with EFI support). The
runtime serv
Signed-off-by: Mark Salter
CC: Catalin Marinas
CC: Will Deacon
CC: linux-arm-ker...@lists.infradead.org
CC: matt.flem...@intel.com
CC: linux-efi@vger.kernel.org
CC: linux-...@vger.kernel.org
CC: Rob Landley
CC: Leif Lindholm
CC: roy.fr...@linaro.org
---
Documentation/arm64/booting.txt | 4 +
Hi Matthew,
於 五，2013-11-29 於 14:44 -0500，Matthew Garrett 提到：
>
> UEFI time services are often broken once we're in virtual mode. We
> were
> already refusing to use them on 64-bit systems, but it turns out that
> they're also broken on some 32-bit firmware, including the Dell Venue.
> Disable th
UEFI time services are often broken once we're in virtual mode. We were
already refusing to use them on 64-bit systems, but it turns out that
they're also broken on some 32-bit firmware, including the Dell Venue.
Disable them for now, we can revisit once we have the 1:1 mappings code
incorporated.
On Fri, Nov 29, 2013 at 11:53:19AM +, Matt Fleming wrote:
> On Thu, 28 Nov, at 04:41:20PM, Leif Lindholm wrote:
> > In systems based on [U]EFI-conformant firmware, runtime services provide
> > a standardised way for the kernel to update firmware environment
> > variables. This is used for examp
Hi Will,
Thanks for having a look.
On Fri, Nov 29, 2013 at 04:10:16PM +, Will Deacon wrote:
> > This patch implements basic support for UEFI runtime services in the
> > ARM architecture - a requirement for using efibootmgr to read and update
> > the system boot configuration.
> >
> > It uses
On Fri, Nov 29, 2013 at 04:28:22PM +0800, Dave Young wrote:
> I think for anyone who are using early_memremap should know this is a
> normal kernel memory instead of real __iomem
You can never ever assume that people are using kernel interfaces
correctly.
--
Regards/Gruss,
Boris.
Sent from
On Fri, Nov 29, 2013 at 04:35:52PM +0800, Dave Young wrote:
> Is below changes ok to you?
Almost perfect! Just a micro-nitpick below:
> Currently e820_reserve_setup_data is called before parsing early params,
> it works in normal case. But for memmap=exactmap, the final memory ranges
> are create
On Fri, Nov 29, 2013 at 04:50:50PM +0800, Dave Young wrote:
> It's for debugging purpose, I think it's helpful.
Why? The first kernel did dump it already.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "un
On Fri, Nov 29, 2013 at 05:14:16PM +0800, Dave Young wrote:
> That's reserved for future extension use, who knows if we will need to
> pass other fields in the future.
Hrrmmm, 8*64 = 64 Bytes?? And you can't change it later because of the
situation where machines might be using older kexec-tools?
Hi Leif,
On Thu, Nov 28, 2013 at 04:41:22PM +, Leif Lindholm wrote:
> This patch implements basic support for UEFI runtime services in the
> ARM architecture - a requirement for using efibootmgr to read and update
> the system boot configuration.
>
> It uses the generic configuration table sc
Hi guys,
The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-urgent
for you to fetch changes up to fdeadb43fdf
On Fri, 29 Nov, at 12:50:29PM, Borislav Petkov wrote:
> > I did not add KEXEC because I thought it can be used for debugging
> > purpose.
>
> mfleming is thinking about it :)
I finally finished my thought. The sysfs code should be automatically
enabled only if CONFIG_KEXEC is enabled, and not on
On Thu, 28 Nov, at 04:41:20PM, Leif Lindholm wrote:
> In systems based on [U]EFI-conformant firmware, runtime services provide
> a standardised way for the kernel to update firmware environment
> variables. This is used for example by efibootmgr to update which image
> should be loaded on next boot
On Fri, Nov 29, 2013 at 05:40:35PM +0800, Dave Young wrote:
> Matt are suggesting to below one, is it ok to you? I'm fine with both.
>
> The efi runtime services can only be switched to virtual mode once
> without rebooting. The kexec kernel must maintain the same physical
> to virtual address mapp
On Wed, 27 Nov, at 03:31:51PM, Roy Franz wrote:
> Both ARM and ARM64 stubs will update the device tree
> that they pass to the kernel. In both cases they
> primarily need to add the same UEFI related information,
> so the function can be shared.
> Create a new FDT related file for this to avoid us
On Wed, 27 Nov, at 03:31:50PM, Roy Franz wrote:
> Update efi-stub.txt documentation to be more general
> and not x86 specific. Add ARM only "dtb=" command
> line option description.
>
> Signed-off-by: Roy Franz
> ---
> Documentation/efi-stub.txt | 27 ---
> 1 file chan
On 11/27/13 at 10:17am, Matt Fleming wrote:
> On Wed, 27 Nov, at 12:52:37PM, Dave Young wrote:
> > To make it more readable, I will change them like below:
> >
> > p = efi_runtime_map;
> > md = efi_setup->map;
> > for (i = 0; i < nr_efi_runtime_map; i++) {
> > [...]
> > md += 1;
> > }
>
On 11/27/13 at 11:20am, Matt Fleming wrote:
> On Tue, 26 Nov, at 01:57:55PM, Dave Young wrote:
> > +Users:
> > + Kexec Mailing List
>
> "Kexec" please.
Will change
>
> > +static ssize_t version_show(struct kobject *kobj,
> > + struct kobj_attribute *
On 11/27/13 at 12:44pm, Borislav Petkov wrote:
> On Tue, Nov 26, 2013 at 01:57:51PM +0800, Dave Young wrote:
> > kexec kernel will need exactly same mapping for
> > efi runtime memory ranges. Thus here export the
> > runtime ranges mapping to sysfs, kexec-tools
> > will assemble them and pass to 2n
On 11/27/13 at 03:07pm, Borislav Petkov wrote:
> On Tue, Nov 26, 2013 at 01:57:52PM +0800, Dave Young wrote:
> > Add a new setup_data type SETUP_EFI for kexec use.
> > Passing the saved fw_vendor, runtime, config tables and
> > efi runtime mappings.
> >
> > When entering virtual mode, directly map
On 11/27/13 at 03:27pm, Borislav Petkov wrote:
> On Wed, Nov 27, 2013 at 10:27:01AM +, Matt Fleming wrote:
> > Heh, you can probably already guess what I'm going to say here...
>
> I guessed :-)
>
> > How about using a single function to dump the memory ranges irrespective
> > of whether the
On 11/27/13 at 10:27am, Matt Fleming wrote:
> On Tue, 26 Nov, at 01:57:53PM, Dave Young wrote:
> > For kexec/kdump kernel efi runtime mappings are saved, printing original
> > whole
> > memmap ranges does not make sense anymore. So introduce a new function to
> > only
> > print runtime maps in ca
On 11/27/13 at 03:27pm, Borislav Petkov wrote:
> On Tue, Nov 26, 2013 at 01:57:54PM +0800, Dave Young wrote:
> > Old kexec-tools can not load new kernel. The reason is previously
> > kexec-tools
>
> The reason is, kexec-tools ... previously, thus efi failed to initialize ...
Good suggestion
>
On 11/27/13 at 03:56pm, Borislav Petkov wrote:
> On Tue, Nov 26, 2013 at 01:57:55PM +0800, Dave Young wrote:
> > kexec-tools use boot_params for getting the 1st kernel hardware_subarch,
> > the kexec kernel efi runtime support also need read the old efi_info from
> > boot_params. Currently it exist
On 11/27/13 at 04:07pm, Borislav Petkov wrote:
> On Tue, Nov 26, 2013 at 01:57:56PM +0800, Dave Young wrote:
> > Kdump kernel using memmap=exactmap, move e820_reserve_setup_data after
> > parsing early params so they can be set reserved finally. Or kdump kernel
> > will warn about ioremap a normal
On 11/28/13 at 10:08am, Dave Young wrote:
> On 11/27/13 at 12:50pm, Matt Fleming wrote:
> > On Tue, 26 Nov, at 01:57:45PM, Dave Young wrote:
> > > Hi,
> > >
> > > Here is the V4 resend for supporting kexec kernel efi runtime.
> > > Per pervious discussion I pass the 1st kernel efi runtime mapping
31 matches
Mail list logo
