On 09/19/13 at 04:54pm, Borislav Petkov wrote:
From: Borislav Petkov b...@suse.de
Hi all,
here's finally a new version of the runtime services VA mapping patchset
which hopefully implements hpa's idea of statically mapping EFI runtime
regions in a top-down manner starting at -4Gb virtual.
* Matt Fleming m...@console-pimps.org wrote:
Hi,
The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f:
Linux 3.12-rc1 (2013-09-16 16:17:51 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git
On 09/20/13 at 03:29pm, Dave Young wrote:
On 09/19/13 at 04:54pm, Borislav Petkov wrote:
From: Borislav Petkov b...@suse.de
Hi all,
here's finally a new version of the runtime services VA mapping patchset
which hopefully implements hpa's idea of statically mapping EFI runtime
On Fri, Sep 20, 2013 at 03:29:04PM +0800, Dave Young wrote:
Just tested this series, for 1st kernel It boots ok in qemu+ovmf. But
it immediately reboot on my Thinkpad T420. Unfortunately there's no
way to debug this very early problem because there's no serial port
also earlyprintk does not
On Wed, 18 Sep, at 01:24:14PM, jerry.hoem...@hp.com wrote:
Matt,
I conducted the following experiments on a 3.11 kernel:
Jerry, could you paste your memory map from the kernel log?
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line
On Wed, 18 Sep, at 09:48:44PM, Roy Franz wrote:
Would it be acceptable to fix the naming/comments, and convert values
above 126 to '?'
in the current patchset, and address a more thorough fix in another patch set?
The ARM and ARM64 EFI stub patchsets that are mostly complete depend
on this
On Fri, 20 Sep, at 01:02:41AM, Adam Borowski wrote:
Are we on the same page so far? If so, I can make a patch atop yours.
Patches to fix this would be most welcome, though I'd wait until Roy
sends out another version of this patch with the name/comment changes.
This series will eventually end
On Fri, Sep 20, 2013 at 04:19:40PM +0800, Dave Young wrote:
Actually the ovmf testing is qemu-system-x86_64 -kernel , boot from grub
fails as well. Nothing printed on serial. I guess '-kernel' is using efi stub
to boot?
Yes.
Which OVMF are you using? Mine is pretty recent: svn revision 14530
On Fri, 20 Sep, at 11:05:44AM, Borislav Petkov wrote:
But no, 32-bit is not addressed here. Which just dawned on me: Matt, I
probably should keep the ioremapping code for 32-bit, doh. I completely
went 64-bit only here :-)
Yes, please keep the ioremap code. At least for now.
--
Matt Fleming,
On Fri, 20 Sep, at 11:05:44AM, Borislav Petkov wrote:
Another concern is that is it safe for i386 efi boot?
That's why I didn't put a git tree on k.org - I wanted to run tests
myself before Fengguang's robot :)
But no, 32-bit is not addressed here. Which just dawned on me: Matt, I
On Fri, Sep 20, 2013 at 10:49:13AM +0100, Matt Fleming wrote:
/home/build/git/efi/arch/x86/platform/efi/efi.c: In function ‘__map_region’:
/home/build/git/efi/arch/x86/platform/efi/efi.c:753:24: error: ‘struct
real_mode_header’ has no member named ‘trampoline_pgd’
On 09/20/13 at 11:33am, Borislav Petkov wrote:
On Fri, Sep 20, 2013 at 04:19:40PM +0800, Dave Young wrote:
Actually the ovmf testing is qemu-system-x86_64 -kernel , boot from grub
fails as well. Nothing printed on serial. I guess '-kernel' is using efi
stub
to boot?
Yes.
Which OVMF
On 09/20/13 at 11:05am, Borislav Petkov wrote:
On Fri, Sep 20, 2013 at 03:29:04PM +0800, Dave Young wrote:
Just tested this series, for 1st kernel It boots ok in qemu+ovmf. But
it immediately reboot on my Thinkpad T420. Unfortunately there's no
way to debug this very early problem because
On 09/20/13 at 01:29pm, Matt Fleming wrote:
On Fri, 20 Sep, at 11:05:44AM, Borislav Petkov wrote:
On Fri, Sep 20, 2013 at 03:29:04PM +0800, Dave Young wrote:
Just tested this series, for 1st kernel It boots ok in qemu+ovmf. But
it immediately reboot on my Thinkpad T420. Unfortunately
A general note:
In multiline comments like:
/* Relocate a kernel image, either compressed or uncompressed.
* In the ARM64 case, all kernel images are currently
* uncompressed, and as such when we relocate it we need to
* allocate additional space for the BSS segment. Any low
* memory that
On 09/20/2013 04:27 AM, Matt Fleming wrote:
On Wed, 18 Sep, at 09:48:44PM, Roy Franz wrote:
Would it be acceptable to fix the naming/comments, and convert values
above 126 to '?'
in the current patchset, and address a more thorough fix in another patch
set?
The ARM and ARM64 EFI stub
On Wed, 18 Sep, at 07:28:53PM, Bart Kuivenhoven wrote:
The problem in efi_main was that the idt was cleared before the
interrupts were disabled.
The UEFI spec states that interrupts aren't used so this shouldn't be
too much of a problem. Peripherals however don't necessarily know about
this
On Fri, 2013-09-20 at 16:28 +0100, Matt Fleming wrote:
On Wed, 18 Sep, at 07:28:53PM, Bart Kuivenhoven wrote:
The problem in efi_main was that the idt was cleared before the
interrupts were disabled.
The UEFI spec states that interrupts aren't used so this shouldn't be
too much of a
18 matches
Mail list logo
