Huang, Ying wrote:
>
> My intention is that we have 3 possible schemes for kernel to use boot
> information.
>
That's not an intention, it's an observation.
> 1. Use "linked list" only. Then if booted with old bootloader which uses
> "zero page" protocol, the "zero page" information provided
On Thu, 2007-08-23 at 00:28 +0800, H. Peter Anvin wrote:
> huang ying wrote:
> >
> > My proposal: Use Peter proposed "linked list of struct setup_data"
> > style boot protocol as long term goal.
> >
> > To smooth the transforming process, the following back compatible
> > scheme can be taken:
> >
Eric W. Biederman wrote:
> I need to review HPA changes a little more from his rewrite in C.
> I think he messed up with the guarantee of initialization in that
> rewrite, but I'm not quite certain.
I beg to differ, sir!
In my rewritten code, the "zeropage" is 4K of zero-initialized .bss,
into
huang ying wrote:
>
> My proposal: Use Peter proposed "linked list of struct setup_data"
> style boot protocol as long term goal.
>
> To smooth the transforming process, the following back compatible
> scheme can be taken:
>
> 1. Keep zero page as an informal external boot protocol, and marked
Andi Kleen <[EMAIL PROTECTED]> writes:
> On Tue, Aug 21, 2007 at 11:43:38PM -0700, Yinghai Lu wrote:
>> On 8/21/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
>> > > current LinuxBIOS's path: the elfboot in LinuxBIOS will prepare the
>> > > e820 table, and jump to startup_32 in kernel. is that not
On 8/22/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> The short term fix is probably to just add a version number to
> the zero page and make sure new changes only add stuff to the
> end and the kernel has reasonable compat code for old versions.
>
> Then LinuxBIOS would need to be changed to supply
On Tue, Aug 21, 2007 at 11:43:38PM -0700, Yinghai Lu wrote:
> On 8/21/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > current LinuxBIOS's path: the elfboot in LinuxBIOS will prepare the
> > > e820 table, and jump to startup_32 in kernel. is that not good and
> > > simple?
> >
> > The problem is
On 8/21/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > current LinuxBIOS's path: the elfboot in LinuxBIOS will prepare the
> > e820 table, and jump to startup_32 in kernel. is that not good and
> > simple?
>
> The problem is that the zero page cannot be changed at all in this
> setup. Or rather it
On 8/21/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > current LinuxBIOS's path: the elfboot in LinuxBIOS will prepare the
> > e820 table, and jump to startup_32 in kernel. is that not good and
> > simple?
>
> The problem is that the zero page cannot be changed at all in this
> setup. Or rather it
On 8/21/07, Andi Kleen [EMAIL PROTECTED] wrote:
current LinuxBIOS's path: the elfboot in LinuxBIOS will prepare the
e820 table, and jump to startup_32 in kernel. is that not good and
simple?
The problem is that the zero page cannot be changed at all in this
setup. Or rather it can be only
On 8/21/07, Andi Kleen [EMAIL PROTECTED] wrote:
current LinuxBIOS's path: the elfboot in LinuxBIOS will prepare the
e820 table, and jump to startup_32 in kernel. is that not good and
simple?
The problem is that the zero page cannot be changed at all in this
setup. Or rather it can be only
On Tue, Aug 21, 2007 at 11:43:38PM -0700, Yinghai Lu wrote:
On 8/21/07, Andi Kleen [EMAIL PROTECTED] wrote:
current LinuxBIOS's path: the elfboot in LinuxBIOS will prepare the
e820 table, and jump to startup_32 in kernel. is that not good and
simple?
The problem is that the zero page
On 8/22/07, Andi Kleen [EMAIL PROTECTED] wrote:
The short term fix is probably to just add a version number to
the zero page and make sure new changes only add stuff to the
end and the kernel has reasonable compat code for old versions.
Then LinuxBIOS would need to be changed to supply that
Andi Kleen [EMAIL PROTECTED] writes:
On Tue, Aug 21, 2007 at 11:43:38PM -0700, Yinghai Lu wrote:
On 8/21/07, Andi Kleen [EMAIL PROTECTED] wrote:
current LinuxBIOS's path: the elfboot in LinuxBIOS will prepare the
e820 table, and jump to startup_32 in kernel. is that not good and
huang ying wrote:
My proposal: Use Peter proposed linked list of struct setup_data
style boot protocol as long term goal.
To smooth the transforming process, the following back compatible
scheme can be taken:
1. Keep zero page as an informal external boot protocol, and marked it
as
Eric W. Biederman wrote:
I need to review HPA changes a little more from his rewrite in C.
I think he messed up with the guarantee of initialization in that
rewrite, but I'm not quite certain.
I beg to differ, sir!
In my rewritten code, the zeropage is 4K of zero-initialized .bss,
into which
On Thu, 2007-08-23 at 00:28 +0800, H. Peter Anvin wrote:
huang ying wrote:
My proposal: Use Peter proposed linked list of struct setup_data
style boot protocol as long term goal.
To smooth the transforming process, the following back compatible
scheme can be taken:
1. Keep zero
Huang, Ying wrote:
My intention is that we have 3 possible schemes for kernel to use boot
information.
That's not an intention, it's an observation.
1. Use linked list only. Then if booted with old bootloader which uses
zero page protocol, the zero page information provided by bootloader
> current LinuxBIOS's path: the elfboot in LinuxBIOS will prepare the
> e820 table, and jump to startup_32 in kernel. is that not good and
> simple?
The problem is that the zero page cannot be changed at all in this
setup. Or rather it can be only changed by breaking LinuxBios.
-Andi
-
To
On 8/21/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 21, 2007 at 03:41:44AM -0700, H. Peter Anvin wrote:
> > Andi Kleen wrote:
> > >> - "struct boot_params" (the zeropage) is kept as a legacy interface.
> > >
> > > Legacy interface for what? Just for kexec utils which never should
> >
On Tue, Aug 21, 2007 at 03:41:44AM -0700, H. Peter Anvin wrote:
> Andi Kleen wrote:
> >> - "struct boot_params" (the zeropage) is kept as a legacy interface.
> >
> > Legacy interface for what? Just for kexec utils which never should
> > have been using it anyways keeping backwards cruft around
Andi Kleen wrote:
>> - "struct boot_params" (the zeropage) is kept as a legacy interface.
>
> Legacy interface for what? Just for kexec utils which never should
> have been using it anyways keeping backwards cruft around seems
> misplac.ed
Worse. LinuxBIOS. :(
-hpa
-
To unsubscribe
> - "struct boot_params" (the zeropage) is kept as a legacy interface.
Legacy interface for what? Just for kexec utils which never should
have been using it anyways keeping backwards cruft around seems
misplac.ed
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
- struct boot_params (the zeropage) is kept as a legacy interface.
Legacy interface for what? Just for kexec utils which never should
have been using it anyways keeping backwards cruft around seems
misplac.ed
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
Andi Kleen wrote:
- struct boot_params (the zeropage) is kept as a legacy interface.
Legacy interface for what? Just for kexec utils which never should
have been using it anyways keeping backwards cruft around seems
misplac.ed
Worse. LinuxBIOS. :(
-hpa
-
To unsubscribe from this
On Tue, Aug 21, 2007 at 03:41:44AM -0700, H. Peter Anvin wrote:
Andi Kleen wrote:
- struct boot_params (the zeropage) is kept as a legacy interface.
Legacy interface for what? Just for kexec utils which never should
have been using it anyways keeping backwards cruft around seems
On 8/21/07, Andi Kleen [EMAIL PROTECTED] wrote:
On Tue, Aug 21, 2007 at 03:41:44AM -0700, H. Peter Anvin wrote:
Andi Kleen wrote:
- struct boot_params (the zeropage) is kept as a legacy interface.
Legacy interface for what? Just for kexec utils which never should
have been using it
current LinuxBIOS's path: the elfboot in LinuxBIOS will prepare the
e820 table, and jump to startup_32 in kernel. is that not good and
simple?
The problem is that the zero page cannot be changed at all in this
setup. Or rather it can be only changed by breaking LinuxBios.
-Andi
-
To
On Mon, 2007-08-20 at 20:54 -0700, H. Peter Anvin wrote:
> Huang, Ying wrote:
> >
> > I think the "next" field can be u32 instead of u64. Because the linked
> > list of struct setup_data is prepared by bootloader, which can control
> > the memory location.
> >
>
> That's making some pretty
Huang, Ying wrote:
>
> I think the "next" field can be u32 instead of u64. Because the linked
> list of struct setup_data is prepared by bootloader, which can control
> the memory location.
>
That's making some pretty serious assumptions on future boot loaders and
environments.
> Previously, I
On Mon, 2007-08-20 at 10:12 -0700, H. Peter Anvin wrote:
> Huang, Ying wrote:
> >>
> >> I propose that, in addition to the aforementioned version number and
> >> magic fields, we add a pointer, which should be the last pointer added
> >> that doesn't point into I/O space or reserved memory (i.e.
On Mon, Aug 20, 2007 at 10:05:11AM -0700, H. Peter Anvin wrote:
> Yinghai Lu wrote:
> >
> > someone told me that EFI PEI will be 32 bit ( for mem etc
> > initialization), and after that will be 64 bit, so the Run time
> > service will be 64 bit only, and it will only support 64 bit OS with
> >
On 8/20/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Yinghai Lu wrote:
> >
> > someone told me that EFI PEI will be 32 bit ( for mem etc
> > initialization), and after that will be 64 bit, so the Run time
> > service will be 64 bit only, and it will only support 64 bit OS with
> > EFI. and they
Huang, Ying wrote:
>>
>> I propose that, in addition to the aforementioned version number and
>> magic fields, we add a pointer, which should be the last pointer added
>> that doesn't point into I/O space or reserved memory (i.e. memory that
>> is off limit anyway for the operating system.)
>>
>>
Yinghai Lu wrote:
>
> someone told me that EFI PEI will be 32 bit ( for mem etc
> initialization), and after that will be 64 bit, so the Run time
> service will be 64 bit only, and it will only support 64 bit OS with
> EFI. and they have another mode to emulate the legacy BIOS to boot
> 32bit OS.
Yinghai Lu wrote:
someone told me that EFI PEI will be 32 bit ( for mem etc
initialization), and after that will be 64 bit, so the Run time
service will be 64 bit only, and it will only support 64 bit OS with
EFI. and they have another mode to emulate the legacy BIOS to boot
32bit OS.
Huang, Ying wrote:
I propose that, in addition to the aforementioned version number and
magic fields, we add a pointer, which should be the last pointer added
that doesn't point into I/O space or reserved memory (i.e. memory that
is off limit anyway for the operating system.)
This pointer
On 8/20/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
Yinghai Lu wrote:
someone told me that EFI PEI will be 32 bit ( for mem etc
initialization), and after that will be 64 bit, so the Run time
service will be 64 bit only, and it will only support 64 bit OS with
EFI. and they have another
On Mon, Aug 20, 2007 at 10:05:11AM -0700, H. Peter Anvin wrote:
Yinghai Lu wrote:
someone told me that EFI PEI will be 32 bit ( for mem etc
initialization), and after that will be 64 bit, so the Run time
service will be 64 bit only, and it will only support 64 bit OS with
EFI. and they
On Mon, 2007-08-20 at 10:12 -0700, H. Peter Anvin wrote:
Huang, Ying wrote:
I propose that, in addition to the aforementioned version number and
magic fields, we add a pointer, which should be the last pointer added
that doesn't point into I/O space or reserved memory (i.e. memory that
Huang, Ying wrote:
I think the next field can be u32 instead of u64. Because the linked
list of struct setup_data is prepared by bootloader, which can control
the memory location.
That's making some pretty serious assumptions on future boot loaders and
environments.
Previously, I think
On Mon, 2007-08-20 at 20:54 -0700, H. Peter Anvin wrote:
Huang, Ying wrote:
I think the next field can be u32 instead of u64. Because the linked
list of struct setup_data is prepared by bootloader, which can control
the memory location.
That's making some pretty serious assumptions
On Sun, 2007-08-19 at 16:25 -0600, Eric W. Biederman wrote:
> "Huang, Ying" <[EMAIL PROTECTED]> writes:
> >> > +#define EFI_LOADER_SIG ((unsigned char *)(PARAM+0x1c0))
> >> > +#define EFI_MEMDESC_SIZE (*((unsigned int *) (PARAM+0x1c4)))
> >> > +#define EFI_MEMDESC_VERSION (*((unsigned int *)
On Fri, 2007-08-17 at 09:11 -0700, H. Peter Anvin wrote:
> Huang, Ying wrote:
> >>
> >> Has the zero page documentation and version numbering project
> >> made any progress? I think we cannot merge this without at least
> >> the version number
> >
>
> More than that. You need to be able to boot
On 8/19/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> "Huang, Ying" <[EMAIL PROTECTED]> writes:
>
> > On Thu, 2007-08-16 at 07:22 +0800, H. Peter Anvin wrote:
> >> Andrew Morton wrote:
> >> > On Mon, 13 Aug 2007 15:30:19 +0800
> >> > "Huang, Ying" <[EMAIL PROTECTED]> wrote:
> >> >
> >> >>
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Huang, Ying wrote:
>>
>> One question:
>>
>> The boot_params.efi_info.efi_systab is defined as u32. But it should be
>> u64 on x86_64, because it comes from firmware and is not controlled by
>> bootloader. But, changing it from u32 to u64 will
"Huang, Ying" <[EMAIL PROTECTED]> writes:
> On Thu, 2007-08-16 at 07:22 +0800, H. Peter Anvin wrote:
>> Andrew Morton wrote:
>> > On Mon, 13 Aug 2007 15:30:19 +0800
>> > "Huang, Ying" <[EMAIL PROTECTED]> wrote:
>> >
>> >> Following sets of patches add EFI/UEFI (Unified Extensible Firmware
>> >>
Huang, Ying [EMAIL PROTECTED] writes:
On Thu, 2007-08-16 at 07:22 +0800, H. Peter Anvin wrote:
Andrew Morton wrote:
On Mon, 13 Aug 2007 15:30:19 +0800
Huang, Ying [EMAIL PROTECTED] wrote:
Following sets of patches add EFI/UEFI (Unified Extensible Firmware
Interface) runtime services
H. Peter Anvin [EMAIL PROTECTED] writes:
Huang, Ying wrote:
One question:
The boot_params.efi_info.efi_systab is defined as u32. But it should be
u64 on x86_64, because it comes from firmware and is not controlled by
bootloader. But, changing it from u32 to u64 will break current i386
On 8/19/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
Huang, Ying [EMAIL PROTECTED] writes:
On Thu, 2007-08-16 at 07:22 +0800, H. Peter Anvin wrote:
Andrew Morton wrote:
On Mon, 13 Aug 2007 15:30:19 +0800
Huang, Ying [EMAIL PROTECTED] wrote:
Following sets of patches add
On Fri, 2007-08-17 at 09:11 -0700, H. Peter Anvin wrote:
Huang, Ying wrote:
Has the zero page documentation and version numbering project
made any progress? I think we cannot merge this without at least
the version number
More than that. You need to be able to boot a 32-bit kernel
On Sun, 2007-08-19 at 16:25 -0600, Eric W. Biederman wrote:
Huang, Ying [EMAIL PROTECTED] writes:
+#define EFI_LOADER_SIG ((unsigned char *)(PARAM+0x1c0))
+#define EFI_MEMDESC_SIZE (*((unsigned int *) (PARAM+0x1c4)))
+#define EFI_MEMDESC_VERSION (*((unsigned int *) (PARAM+0x1c8)))
Huang, Ying wrote:
>>
>> Has the zero page documentation and version numbering project
>> made any progress? I think we cannot merge this without at least
>> the version number
>
More than that. You need to be able to boot a 32-bit kernel on a 64-bit
system, so anything that breaks that is a
Huang, Ying wrote:
Has the zero page documentation and version numbering project
made any progress? I think we cannot merge this without at least
the version number
More than that. You need to be able to boot a 32-bit kernel on a 64-bit
system, so anything that breaks that is a nonstarter.
On Thu, 2007-08-16 at 16:11 +0200, Andi Kleen wrote:
> Huang, Ying wrote:
> > On Thu, 2007-08-16 at 06:42 +0800, Andrew Morton wrote:
> >> On Mon, 13 Aug 2007 15:30:19 +0800
> >> "Huang, Ying" <[EMAIL PROTECTED]> wrote:
> >>
> >>> Following sets of patches add EFI/UEFI (Unified Extensible Firmware
Huang, Ying wrote:
>
> One question:
>
> The boot_params.efi_info.efi_systab is defined as u32. But it should be
> u64 on x86_64, because it comes from firmware and is not controlled by
> bootloader. But, changing it from u32 to u64 will break current i386 EFI
> support, should we change it and
Huang, Ying wrote:
> On Thu, 2007-08-16 at 06:42 +0800, Andrew Morton wrote:
>> On Mon, 13 Aug 2007 15:30:19 +0800
>> "Huang, Ying" <[EMAIL PROTECTED]> wrote:
>>
>>> Following sets of patches add EFI/UEFI (Unified Extensible Firmware
>>> Interface) runtime services support to x86_64 architecture.
On Thu, 2007-08-16 at 07:22 +0800, H. Peter Anvin wrote:
> Andrew Morton wrote:
> > On Mon, 13 Aug 2007 15:30:19 +0800
> > "Huang, Ying" <[EMAIL PROTECTED]> wrote:
> >
> >> Following sets of patches add EFI/UEFI (Unified Extensible Firmware
> >> Interface) runtime services support to x86_64
On Thu, 2007-08-16 at 07:16 +0800, Andrew Morton wrote:
> On Mon, 13 Aug 2007 15:30:19 +0800
> "Huang, Ying" <[EMAIL PROTECTED]> wrote:
>
> > Following sets of patches add EFI/UEFI (Unified Extensible Firmware
> > Interface) runtime services support to x86_64 architecture.
>
> OK, we have a
On Thu, 2007-08-16 at 06:42 +0800, Andrew Morton wrote:
> On Mon, 13 Aug 2007 15:30:19 +0800
> "Huang, Ying" <[EMAIL PROTECTED]> wrote:
>
> > Following sets of patches add EFI/UEFI (Unified Extensible Firmware
> > Interface) runtime services support to x86_64 architecture.
>
> I had to rework
On Thu, 2007-08-16 at 06:42 +0800, Andrew Morton wrote:
On Mon, 13 Aug 2007 15:30:19 +0800
Huang, Ying [EMAIL PROTECTED] wrote:
Following sets of patches add EFI/UEFI (Unified Extensible Firmware
Interface) runtime services support to x86_64 architecture.
I had to rework these a bit due
On Thu, 2007-08-16 at 07:16 +0800, Andrew Morton wrote:
On Mon, 13 Aug 2007 15:30:19 +0800
Huang, Ying [EMAIL PROTECTED] wrote:
Following sets of patches add EFI/UEFI (Unified Extensible Firmware
Interface) runtime services support to x86_64 architecture.
OK, we have a major trainwreck
On Thu, 2007-08-16 at 07:22 +0800, H. Peter Anvin wrote:
Andrew Morton wrote:
On Mon, 13 Aug 2007 15:30:19 +0800
Huang, Ying [EMAIL PROTECTED] wrote:
Following sets of patches add EFI/UEFI (Unified Extensible Firmware
Interface) runtime services support to x86_64 architecture.
OK,
Huang, Ying wrote:
On Thu, 2007-08-16 at 06:42 +0800, Andrew Morton wrote:
On Mon, 13 Aug 2007 15:30:19 +0800
Huang, Ying [EMAIL PROTECTED] wrote:
Following sets of patches add EFI/UEFI (Unified Extensible Firmware
Interface) runtime services support to x86_64 architecture.
I had to rework
Huang, Ying wrote:
One question:
The boot_params.efi_info.efi_systab is defined as u32. But it should be
u64 on x86_64, because it comes from firmware and is not controlled by
bootloader. But, changing it from u32 to u64 will break current i386 EFI
support, should we change it and fix the
On Thu, 2007-08-16 at 16:11 +0200, Andi Kleen wrote:
Huang, Ying wrote:
On Thu, 2007-08-16 at 06:42 +0800, Andrew Morton wrote:
On Mon, 13 Aug 2007 15:30:19 +0800
Huang, Ying [EMAIL PROTECTED] wrote:
Following sets of patches add EFI/UEFI (Unified Extensible Firmware
Interface)
Andrew Morton wrote:
> On Mon, 13 Aug 2007 15:30:19 +0800
> "Huang, Ying" <[EMAIL PROTECTED]> wrote:
>
>> Following sets of patches add EFI/UEFI (Unified Extensible Firmware
>> Interface) runtime services support to x86_64 architecture.
>
> OK, we have a major trainwreck when these patches meet
On Mon, 13 Aug 2007 15:30:19 +0800
"Huang, Ying" <[EMAIL PROTECTED]> wrote:
> Following sets of patches add EFI/UEFI (Unified Extensible Firmware
> Interface) runtime services support to x86_64 architecture.
OK, we have a major trainwreck when these patches meet Peter's
get-newsetup.patch.
I'm
On Mon, 13 Aug 2007 15:30:19 +0800
"Huang, Ying" <[EMAIL PROTECTED]> wrote:
> Following sets of patches add EFI/UEFI (Unified Extensible Firmware
> Interface) runtime services support to x86_64 architecture.
I had to rework these a bit due to clashes with
x86_64-add-acpi-reboot-option.patch.
On Mon, 13 Aug 2007 15:30:19 +0800
Huang, Ying [EMAIL PROTECTED] wrote:
Following sets of patches add EFI/UEFI (Unified Extensible Firmware
Interface) runtime services support to x86_64 architecture.
I had to rework these a bit due to clashes with
x86_64-add-acpi-reboot-option.patch. Please
On Mon, 13 Aug 2007 15:30:19 +0800
Huang, Ying [EMAIL PROTECTED] wrote:
Following sets of patches add EFI/UEFI (Unified Extensible Firmware
Interface) runtime services support to x86_64 architecture.
OK, we have a major trainwreck when these patches meet Peter's
get-newsetup.patch.
I'm
Andrew Morton wrote:
On Mon, 13 Aug 2007 15:30:19 +0800
Huang, Ying [EMAIL PROTECTED] wrote:
Following sets of patches add EFI/UEFI (Unified Extensible Firmware
Interface) runtime services support to x86_64 architecture.
OK, we have a major trainwreck when these patches meet Peter's
Following sets of patches add EFI/UEFI (Unified Extensible Firmware
Interface) runtime services support to x86_64 architecture. The
patches have been tested against 2.6.23-rc2 kernel on Intel platforms
with EFI1.10 and UEFI2.0 firmware. This patch set is based on previous
x86_64 EFI boot support
Following sets of patches add EFI/UEFI (Unified Extensible Firmware
Interface) runtime services support to x86_64 architecture. The
patches have been tested against 2.6.23-rc2 kernel on Intel platforms
with EFI1.10 and UEFI2.0 firmware. This patch set is based on previous
x86_64 EFI boot support
74 matches
Mail list logo
