Re: ping (update-grub2)
On Monday 27 November 2006 18:00, Robert Millan wrote:
> No comments? Are you interested in getting this into the main grub tree?
> In my opinion, since update-grub needs a rewrite it's a good oportunity to
> merge this now and unify grub.cfg generation across distributions
> (something that wasn't possible with the old update-grub because of
> copyright issues).
>
> That said, if you don't like the idea then we could proceed adding it in
> debian, but that might close the door to merging in the future (maintaining
> the script in debian ourselves implies accepting contributions from many
> people without any paperwork arrangements).
I describe my own opinion. If others do not agree, let me know.
If the script is generic enough, and other projects are willing to use it, it
is convenient to put it in official versions ("official" means "upstream" in
Debian, but I don't like the term "upstream" very much, BTW). So, in this
case, I accept it. But if it is used only for Debian, I don't think it is
worth doing.
I know it is not so nice to put distribution-specific scripts in official
versions with my past experience, because official versions are not always
synchronized with distribution versions, so when a script in an official
version is "outdated" for a distribution, it is necessary to locally patch
the script, and this effort can be quite painful, if you always need to make
patches for every version.
That's why we don't have the directory "debian" any longer. We had it in GRUB
legacy in version 0.5.92 or something when Gordon was the maintainer of the
GRUB package in Debian. But this became really annoying after Gordon got
inactive, because I had no idea on how to maintain it, as I was not a Debian
user then. And, someone (I think he was Jason Thomas) complained, and I
decided to drop it from the official version.
Okuji
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot2: variable data size
"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes: > On Saturday 25 November 2006 04:33, Hollis Blanchard wrote: >> That's exactly the point: there will be no difference. Both >> architectures will use 64-bit types. > > No. Both should use 32-bit, because GRUB transfers control in 32-bit mode. > Passing 64-bit addresses would be useless in this case. Note that the memory > map information is 64-bit even in the previous version of Multiboot Spec. That will not be true for x86_64-efi, which will have to run in long mode. ~j pgpllOc4H2Fni.pgp Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] multiboot2 loader
On Tue, Nov 28, 2006 at 08:11:37AM +0100, Yoshinori K. Okuji wrote: > On Sunday 26 November 2006 23:50, Jeroen Dekkers wrote: > > Nothing prevents you from writing a C library - the POSIX and C > > standards are available independently. Yet the C library is under > > LGPL. Also nothing prevents you from writing an ogg vorbis > > implementation, but the FSF advocated the BSD license for ogg vorbis > > however. > > > > What RMS said is that the GPL isn't an end itself. I agree with that, > > and I think the BSD license is more suitable for the multiboot header > > files and/or multiboot example kernel than the GPL. > > You are right at the point that we adopt weaker licenses by compromise from > time to time. But you completely miss the point that code in GRUB is not > meant to be used for other projects. So we have no reason to compromise in > GRUB. You completely miss the point that we want to have header files and example code that can be used by other projects to implement multiboot. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] multiboot2 loader
On Tue, Nov 28, 2006 at 08:08:46AM +0100, Yoshinori K. Okuji wrote: > On Sunday 26 November 2006 11:18, Tomáš Ebenlendr wrote: > > What about having > > "Multiboot's" header as a part of "Multiboot project". > > Multiboot Specification is not a part of GRUB in any sense. It is discussed > in > this list, only because that is the most realistic at the moment, as all > Multiboot developers are GRUB developers, too, AFAIK. Not part of GRUB in any sense? It was developed by GRUB developers, has always been living in the GRUB repository, the official GRUB tarball includes it and AFAIK GRUB is the only bootloader to implement it. Saying that multiboot isn't part of GRUB doesn't really make any sense to me. It could as well have been named "GRUB boot protocol" and nobody would consider that strange. Jeroen Dekkers ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] multiboot2 loader
On Tuesday 28 November 2006 11:59, Jeroen Dekkers wrote: > You completely miss the point that we want to have header files and > example code that can be used by other projects to implement > multiboot. *sigh* Sleep well, and reconsider what I have said. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] multiboot2 loader
On Tuesday 28 November 2006 11:59, Jeroen Dekkers wrote: > On Tue, Nov 28, 2006 at 08:08:46AM +0100, Yoshinori K. Okuji wrote: > > On Sunday 26 November 2006 11:18, Tomáš Ebenlendr wrote: > > > What about having > > > "Multiboot's" header as a part of "Multiboot project". > > > > Multiboot Specification is not a part of GRUB in any sense. It is > > discussed in this list, only because that is the most realistic at the > > moment, as all Multiboot developers are GRUB developers, too, AFAIK. > > Not part of GRUB in any sense? No. It is explicitly written that this specification is to define a neutral protocol between a boot loader and an operating system. > It was developed by GRUB developers, > has always been living in the GRUB repository, the official GRUB > tarball includes it and AFAIK GRUB is the only bootloader to implement > it. I know at least one more project which implements Multiboot: Etherboot. The support is partial, but it still supports Multiboot. I talked about excluding the Multiboot Specification from GRUB with RMS a long time ago, because it was not really a part of GRUB, and it looked like a part of it, although it should be regarded as a generic specification, only because it was bundled with GRUB. And, he said that it was more convenient for people who would like to utilize GRUB to include the spec, and the spec was small enough to distribute with GRUB. His argument sounded good, so I decided to keep it. But now it might be better to change my mind, since even _you_ misunderstand it. If you don't get it, how many people would understand? > Saying that multiboot isn't part of GRUB doesn't really make any > sense to me. It could as well have been named "GRUB boot protocol" and > nobody would consider that strange. Don't generalize your idea without asking. The spec is not limited to GRUB, and GRUB supports more protocols. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot2: variable data size
On Tuesday 28 November 2006 10:29, Johan Rydberg wrote: > "Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes: > > On Saturday 25 November 2006 04:33, Hollis Blanchard wrote: > >> That's exactly the point: there will be no difference. Both > >> architectures will use 64-bit types. > > > > No. Both should use 32-bit, because GRUB transfers control in 32-bit > > mode. Passing 64-bit addresses would be useless in this case. Note that > > the memory map information is 64-bit even in the previous version of > > Multiboot Spec. > > That will not be true for x86_64-efi, which will have to run in long > mode. Oh, sorry. I meant "x86_64-pc" in the previous message. I just omitted "pc". When the firmware is different, it is feasible to make a different spec, but... But is it true that EFI starts with 64-bit mode? Where is it defined? In UEFI? Could you give me a pointer? Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot2: variable data size
Yoshinori K. Okuji wrote: On Tuesday 28 November 2006 10:29, Johan Rydberg wrote: > "Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes: > > On Saturday 25 November 2006 04:33, Hollis Blanchard wrote: > >> That's exactly the point: there will be no difference. Both > >> architectures will use 64-bit types. > > > > No. Both should use 32-bit, because GRUB transfers control in 32-bit > > mode. Passing 64-bit addresses would be useless in this case. Note that > > the memory map information is 64-bit even in the previous version of > > Multiboot Spec. > > That will not be true for x86_64-efi, which will have to run in long > mode. Oh, sorry. I meant "x86_64-pc" in the previous message. I just omitted "pc". When the firmware is different, it is feasible to make a different spec, but... But is it true that EFI starts with 64-bit mode? Where is it defined? In UEFI? Could you give me a pointer? yes, x84_64EFI starts with 64-bit long mode and page enabled(virtual address equals physical address) if it is x86_64 efi bios, it is defined in section 2.3.4 of UEFI Specification Version 2.0. If kernel image is bzImage, x64 efi bootloader need switch to 32 bit protect mode(or real mode) from 64 bit long mode, and if kernel image is gzipped/plain format, efi bootloader can directly jump to 64-bit kernel entry address without mode switch. thanks bibo,mao ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot2: variable data size
Quoting "Yoshinori K. Okuji" <[EMAIL PROTECTED]>: > On Tuesday 28 November 2006 10:29, Johan Rydberg wrote: > > "Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes: > > > On Saturday 25 November 2006 04:33, Hollis Blanchard wrote: > > >> That's exactly the point: there will be no difference. Both > > >> architectures will use 64-bit types. > > > > > > No. Both should use 32-bit, because GRUB transfers control in 32-bit > > > mode. Passing 64-bit addresses would be useless in this case. Note that > > > the memory map information is 64-bit even in the previous version of > > > Multiboot Spec. > > > > That will not be true for x86_64-efi, which will have to run in long > > mode. > > Oh, sorry. I meant "x86_64-pc" in the previous message. I just omitted "pc". > When the firmware is different, it is feasible to make a different spec, > but... > > But is it true that EFI starts with 64-bit mode? Where is it defined? In > UEFI? > Could you give me a pointer? Yes, cf tianocore.org. When compiled for x64, it is x64 code :-) Tristan. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot2: variable data size
On Tuesday 28 November 2006 13:46, bibo,mao wrote: > yes, x84_64EFI starts with 64-bit long mode and page enabled(virtual > address equals physical address) if it is x86_64 efi bios, it is defined in > section 2.3.4 of UEFI Specification Version 2.0. > > If kernel image is bzImage, x64 efi bootloader need switch to 32 bit > protect mode(or real mode) from 64 bit long mode, and if kernel image is > gzipped/plain format, efi bootloader can directly jump to 64-bit kernel > entry address without mode switch. Thanks for your detailed information. So does it mean that GRUB needs to provide a PE32+ application to EFI, if it is on x86_64? Or does it understand PE32? More information is welcome. BTW, in the current implementation, GRUB skips real mode setup code in Linux and directly jumps to a protected mode entry on EFI. Can we use the same trick with bzImage on x86_64? Mode switching is not difficult, but if we can omit it, that would be much easier to implement. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot2: variable data size
"bibo,mao" <[EMAIL PROTECTED]> writes: > If kernel image is bzImage, x64 efi bootloader need switch to 32 bit > protect mode(or real mode) from 64 bit long mode, and if kernel > image is gzipped/plain format, efi bootloader can directly jump to > 64-bit kernel entry address without mode switch. My opinion is that bzImages should be avoided on EFI platforms, or the decompress-code in Linux has to be rewritten. It took me a good couple of hours of debugging to find out that Linux simply ignores the memory layout and assumes that low memory is free to use as it likes. ~j pgp5cBeUfo6bB.pgp Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot2: variable data size
Yoshinori K. Okuji wrote: On Tuesday 28 November 2006 13:46, bibo,mao wrote: > yes, x84_64EFI starts with 64-bit long mode and page enabled(virtual > address equals physical address) if it is x86_64 efi bios, it is defined in > section 2.3.4 of UEFI Specification Version 2.0. > > If kernel image is bzImage, x64 efi bootloader need switch to 32 bit > protect mode(or real mode) from 64 bit long mode, and if kernel image is > gzipped/plain format, efi bootloader can directly jump to 64-bit kernel > entry address without mode switch. Thanks for your detailed information. So does it mean that GRUB needs to provide a PE32+ application to EFI, if it is on x86_64? Or does it understand PE32? More information is welcome. Now I tried on x86_64, it seems that x86_64 efi bios does not support PE32 format, PE32+ application should be provided. BTW, in the current implementation, GRUB skips real mode setup code in Linux and directly jumps to a protected mode entry on EFI. Can we use the same trick with bzImage on x86_64? Mode switching is not difficult, but if we can omit it, that would be much easier to implement. On i386 efi platform, real mode setup code can be skipped with bzImage. But on x86_64 efi platform with bzImage format, it seems that it need switch to 32-bit protect mode at least. We can discard mode switching at beginning so that it can boot kernel image with gzipped format. Mode switching code is not difficult and very small, the problem is that x86_64 bootloader(pe32+) can be loaded at address beyond 4G, but mode switching code must be within 4G, also self-uncompressed bzimage code possibly flushes mode switching code. I do not know which address is safe to put switching code, how about 0x7c00? thanks bibo,mao Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot2: variable data size
Johan Rydberg wrote: "bibo,mao" <[EMAIL PROTECTED]> writes: > If kernel image is bzImage, x64 efi bootloader need switch to 32 bit > protect mode(or real mode) from 64 bit long mode, and if kernel > image is gzipped/plain format, efi bootloader can directly jump to > 64-bit kernel entry address without mode switch. My opinion is that bzImages should be avoided on EFI platforms, or the decompress-code in Linux has to be rewritten. bzImage supporting mainly is to be compliant with legacy bios, user need not care for detailed bootloader procedure, user always installs linux kernel with command "make install" which will generate bzImage format. Now on some platform there are two kinds of bios: efi bios and legacy bios, if bzImage is supported then one kernel image can run two kinds of bios. It took me a good couple of hours of debugging to find out that Linux simply ignores the memory layout and assumes that low memory is free to use as it likes. current decompress-code with bzImage possibly touches low memory at 0x1000--0x9000, or decompress-code needs to be rewritten, or put mode switching code below 0x1000. thanks bibo,mao ~j ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot2: variable data size
Inlined. On 28.11.2006, at 19:55, bibo,mao wrote: Yoshinori K. Okuji wrote: On Tuesday 28 November 2006 13:46, bibo,mao wrote: > yes, x84_64EFI starts with 64-bit long mode and page enabled (virtual > address equals physical address) if it is x86_64 efi bios, it is defined in > section 2.3.4 of UEFI Specification Version 2.0. > > If kernel image is bzImage, x64 efi bootloader need switch to 32 bit > protect mode(or real mode) from 64 bit long mode, and if kernel image is > gzipped/plain format, efi bootloader can directly jump to 64- bit kernel > entry address without mode switch. Thanks for your detailed information. So does it mean that GRUB needs to provide a PE32+ application to EFI, if it is on x86_64? Or does it understand PE32? More information is welcome. Now I tried on x86_64, it seems that x86_64 efi bios does not support PE32 format, PE32+ application should be provided. Yes. Grub for x64 EFI should be a PE32+ image. BTW, in the current implementation, GRUB skips real mode setup code in Linux and directly jumps to a protected mode entry on EFI. Can we use the same trick with bzImage on x86_64? Mode switching is not difficult, but if we can omit it, that would be much easier to implement. On i386 efi platform, real mode setup code can be skipped with bzImage. But on x86_64 efi platform with bzImage format, it seems that it need switch to 32-bit protect mode at least. We can discard mode switching at beginning so that it can boot kernel image with gzipped format. Mode switching code is not difficult and very small, the problem is that x86_64 bootloader(pe32+) can be loaded at address beyond 4G, but mode switching code must be within 4G, also self-uncompressed bzimage code possibly flushes mode switching code. I do not know which address is safe to put switching code, how about 0x7c00? That is not a problem. AllocatePages() in the UEFI runtime services can be told to allocate memory below a certain address by passing AllocateMaxAddress as the EFI_ALLOCATE_TYPE. The UEFI specification is your friend :) – http://www.uefi.org/ thanks bibo,mao Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
