[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAE9FiQV=G=5zAqv7EiUnb=O7znxuieiCawfgomv9aPNwVAV4uQ@mail.gmail.com>
Date: Mon, 19 Nov 2012 14:53:36 -0800
From: Yinghai Lu <yinghai@...nel.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
linux-kernel@...r.kernel.org, Matt Fleming <matt.fleming@...el.com>
Subject: Re: [PATCH v2 03/13] x86: Add macro for 64bit entry startup_64
On Mon, Nov 19, 2012 at 2:42 PM, H. Peter Anvin <hpa@...or.com> wrote:
> On 11/17/2012 11:09 PM, Yinghai Lu wrote:
>> We will add one 64bit entry for bzImage in boot header struct.
>>
>> the contents in that field will be offset of startup_64.
>>
>> Add macro for offset of startup_64 to keep two places consistent.
>>
>> Signed-off-by: Yinghai Lu <yinghai@...nel.org>
>> Cc: Matt Fleming <matt.fleming@...el.com>
>> ---
>> arch/x86/boot/compressed/head_64.S | 2 +-
>> arch/x86/include/asm/boot.h | 2 ++
>> 2 files changed, 3 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
>> index 375af23..e4964dd 100644
>> --- a/arch/x86/boot/compressed/head_64.S
>> +++ b/arch/x86/boot/compressed/head_64.S
>> @@ -195,7 +195,7 @@ no_longmode:
>> * it may change in the future.
>> */
>> .code64
>> - .org 0x200
>> + .org BOOT_CODE64_START_OFFSET
>> ENTRY(startup_64)
>> /*
>> * We come here either from startup_32 or directly from a
>> diff --git a/arch/x86/include/asm/boot.h b/arch/x86/include/asm/boot.h
>> index b13fe63..ef36497 100644
>> --- a/arch/x86/include/asm/boot.h
>> +++ b/arch/x86/include/asm/boot.h
>> @@ -38,8 +38,10 @@
>>
>> #ifdef CONFIG_X86_64
>> #define BOOT_STACK_SIZE 0x4000
>> +#define BOOT_CODE64_START_OFFSET 0x200
>> #else
>> #define BOOT_STACK_SIZE 0x1000
>> +#define BOOT_CODE64_START_OFFSET 0
>> #endif
>>
>
> We can't change the 0x200 value, ever, because there are already things
> that use the 64-bit entry point. As such, these macros and the bzImage
> fields are pointless; let's not bother and instead document the 0x200 as
> the permanently fixed address of the 64-bit entry point.
ok,
any other field, in header struct field that we can use to tell
bzImage could be used that
0x200 directly?
hardware_subarch?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists