On Fri, 2007-10-26 at 12:31 +0100, Alan Cox wrote:
> On Fri, 26 Oct 2007 09:03:11 +0800
> "Huang, Ying" <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 2007-10-25 at 18:09 +0200, Thomas Gleixner wrote:
> > > > EFI runtime
> > > > services initialization are implemented in efi.c. Some x86_64
> > > > speci
Alan Cox wrote:
Again, these are wrappers to access EFI and not Windows.
EFI uses the Windows x86_64 calling convention. The lin2win may be a
more general naming convention that can be used for some other code (the
NDISwrapper?) in the future. Do you agree?
The SYSV description is wrong as wel
> I still do not understand why we need all this EFI hackery at all
> aside of the possible usage for saving a crash dump on FLASH, which we
> could do directly from the kernel as well.
Battery backed up RAM not Flash. The layout of that RAM is BIOS dependent so
we need some BIOS support for cha
On Fri, 26 Oct 2007 09:03:11 +0800
"Huang, Ying" <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-10-25 at 18:09 +0200, Thomas Gleixner wrote:
> > > EFI runtime
> > > services initialization are implemented in efi.c. Some x86_64
> > > specifics are worth noting here. On x86_64, parameters passed to UEFI
On Fri, 26 Oct 2007, Huang, Ying wrote:
> On Fri, 2007-10-26 at 10:48 +0200, Thomas Gleixner wrote:
> > > EFI uses the Windows x86_64 calling convention. The lin2win may be a
> > > more general naming convention that can be used for some other code (the
> > > NDISwrapper?) in the future. Do you ag
On Fri, 2007-10-26 at 10:48 +0200, Thomas Gleixner wrote:
> > EFI uses the Windows x86_64 calling convention. The lin2win may be a
> > more general naming convention that can be used for some other code (the
> > NDISwrapper?) in the future. Do you agree?
>
> I agree not at all. I do not care wheth
On Fri, 26 Oct 2007, Huang, Ying wrote:
> On Thu, 2007-10-25 at 18:09 +0200, Thomas Gleixner wrote:
> > > EFI runtime
> > > services initialization are implemented in efi.c. Some x86_64
> > > specifics are worth noting here. On x86_64, parameters passed to UEFI
> > > firmware services need to foll
Huang, Ying wrote:
- 3 files: efi.c, efi_32.c, efi_64.c, common code goes in efi.c, EFI
32/64 specific code goes in efi_32/64.c. This will make some variable,
function external instead of static.
This is preferred.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linu
On Thu, 2007-10-25 at 18:09 +0200, Thomas Gleixner wrote:
> On Thu, 25 Oct 2007, Huang, Ying wrote:
>
> > This patch adds basic runtime services support for EFI x86_64
> > system. The main file of the patch is the addition of efi.c for
> > x86_64. This file is modeled after the EFI IA32 avatar.
>
On Thu, 2007-10-25 at 15:29 -0700, H. Peter Anvin wrote:
> Eric W. Biederman wrote:
> > "H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> >
> >> Eric W. Biederman wrote:
> Ying claimed that GOP requires EFI runtime services. Is that not true?
> >>> None of the EFI framebuffer patches that I saw
On Thu, 2007-10-25 at 13:36 -0700, H. Peter Anvin wrote:
> Eric W. Biederman wrote:
> >>>
> >> Ying claimed that GOP requires EFI runtime services. Is that not true?
> >
> > None of the EFI framebuffer patches that I saw used EFI runtime services.
> >
>
> Ying, could you please clarify this sit
On Thu, 2007-10-25 at 11:30 -0600, Eric W. Biederman wrote:
> "H. Peter Anvin" <[EMAIL PROTECTED]> writes:
>
> > Andi Kleen wrote:
> >>> Especially for accessing the real time clock that has a well
> >>> defined hardware interface going through efi an additional
> >>> software emulation layer look
On Thu, 2007-10-25 at 11:06 -0600, Eric W. Biederman wrote:
> Arjan van de Ven <[EMAIL PROTECTED]> writes:
>
> > On Thu, 25 Oct 2007 10:55:44 -0600
> > [EMAIL PROTECTED] (Eric W. Biederman) wrote:
> >
> >> I don't think there is a compelling case for us to use any efi
> >> services at this time
>
On Thu, 2007-10-25 at 11:01 -0600, Eric W. Biederman wrote:
> > +static efi_status_t __init phys_efi_set_virtual_address_map(
> > + unsigned long memory_map_size,
> > + unsigned long descriptor_size,
> > + u32 descriptor_version,
> > + efi_memory_desc_t *virtual_map)
> > +{
> > + efi_stat
On Thu, 2007-10-25 at 18:09 +0200, Thomas Gleixner wrote:
> > EFI runtime
> > services initialization are implemented in efi.c. Some x86_64
> > specifics are worth noting here. On x86_64, parameters passed to UEFI
> > firmware services need to follow the UEFI calling convention. For this
> > purpos
Eric W. Biederman wrote:
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
Eric W. Biederman wrote:
Ying claimed that GOP requires EFI runtime services. Is that not true?
None of the EFI framebuffer patches that I saw used EFI runtime services.
Ying, could you please clarify this situation?
(E
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>> Ying claimed that GOP requires EFI runtime services. Is that not true?
>>
>> None of the EFI framebuffer patches that I saw used EFI runtime services.
>>
>
> Ying, could you please clarify this situation?
>
> (Eric:
Eric W. Biederman wrote:
Ying claimed that GOP requires EFI runtime services. Is that not true?
None of the EFI framebuffer patches that I saw used EFI runtime services.
Ying, could you please clarify this situation?
(Eric: do note that there are two EFI framebuffer standard, UGA and GOP
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>> Well, the original motivation for all of this was to enable implementation
>>> of
> a
>>> EFI framebuffer (UGA/GOP). Now, you can say what you want about EFI (and I
>>> definitely have my opinion on it), but that se
Eric W. Biederman wrote:
Well, the original motivation for all of this was to enable implementation of a
EFI framebuffer (UGA/GOP). Now, you can say what you want about EFI (and I
definitely have my opinion on it), but that seems legitimate to me.
To be very clear. I think we need the EFI b
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Arjan van de Ven wrote:
>> On Thu, 25 Oct 2007 10:55:44 -0600
>> [EMAIL PROTECTED] (Eric W. Biederman) wrote:
>>
>>> I don't think there is a compelling case for us to use any efi
>>> services at this time
>>
>> I would almost agree with this if it wa
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Andi Kleen wrote:
>>> Especially for accessing the real time clock that has a well
>>> defined hardware interface going through efi an additional
>>> software emulation layer looks like asking for trouble.
>>
>> I agree it's pointless for the hardware
Andi Kleen wrote:
Especially for accessing the real time clock that has a well
defined hardware interface going through efi an additional
software emulation layer looks like asking for trouble.
I agree it's pointless for the hardware clock, but EFI
also offers services to write some data to th
Arjan van de Ven wrote:
On Thu, 25 Oct 2007 10:55:44 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
I don't think there is a compelling case for us to use any efi
services at this time
I would almost agree with this if it wasn't for the 1 call that OS
installers need to tell EFI about boo
Arjan van de Ven <[EMAIL PROTECTED]> writes:
> On Thu, 25 Oct 2007 10:55:44 -0600
> [EMAIL PROTECTED] (Eric W. Biederman) wrote:
>
>> I don't think there is a compelling case for us to use any efi
>> services at this time
>
> I would almost agree with this if it wasn't for the 1 call that OS
> ins
"Huang, Ying" <[EMAIL PROTECTED]> writes:
> +static void __init efi_call_phys_prelog(void) __acquires(efi_lock)
> +{
> + unsigned long vaddress;
> +
> + /*
> + * Lock sequence is different from normal case because
> + * efi_flags is global
> + */
> + spin_lock(&efi_lock)
> Especially for accessing the real time clock that has a well
> defined hardware interface going through efi an additional
> software emulation layer looks like asking for trouble.
I agree it's pointless for the hardware clock, but EFI
also offers services to write some data to the CMOS RAM
whi
On Thu, 25 Oct 2007 10:55:44 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
> I don't think there is a compelling case for us to use any efi
> services at this time
I would almost agree with this if it wasn't for the 1 call that OS
installers need to tell EFI about bootloader stuff; I've cc'd
Thomas Gleixner <[EMAIL PROTECTED]> writes:
> On Thu, 25 Oct 2007, Huang, Ying wrote:
>
>> This patch adds basic runtime services support for EFI x86_64
>> system. The main file of the patch is the addition of efi.c for
>> x86_64. This file is modeled after the EFI IA32 avatar.
>
> modeled means c
Thomas Gleixner wrote:
EFI runtime
services initialization are implemented in efi.c. Some x86_64
specifics are worth noting here. On x86_64, parameters passed to UEFI
firmware services need to follow the UEFI calling convention. For this
purpose, a set of functions named lin2win ( is the number
On Thu, 25 Oct 2007, Huang, Ying wrote:
> This patch adds basic runtime services support for EFI x86_64
> system. The main file of the patch is the addition of efi.c for
> x86_64. This file is modeled after the EFI IA32 avatar.
modeled means copied and modified, right?
This is wrong. I compared
This patch adds basic runtime services support for EFI x86_64
system. The main file of the patch is the addition of efi.c for
x86_64. This file is modeled after the EFI IA32 avatar. EFI runtime
services initialization are implemented in efi.c. Some x86_64
specifics are worth noting here. On x86_64,
32 matches
Mail list logo
