Re: Grub for ia64
Tristan Gingold wrote: On Thu, Oct 12, 2006 at 05:32:00PM +0200, Johan Rydberg wrote: > Tristan Gingold <[EMAIL PROTECTED]> writes: > > > On Thu, Oct 12, 2006 at 02:11:57PM +0200, Johan Rydberg wrote: > >> Tristan Gingold <[EMAIL PROTECTED]> writes: > >> > >> >> You're telling me that EFI on your IA-64 system does not relocate the > >> >> program before start executing it? That sounds strange. > >> > > >> > It does relocate EFI PEI images. Unfortunatly there is no tools to create > >> > EFI PEI objects on Linux. The gnu efi tools are kludgy: they use standard > >> > gcc and ld, create an ELF image and convert it to a PEI image. But the > >> > relocations are not converted, they are simply put into the data section. > >> > >> How hard would it be to write a converter ourselves, starting with > >> util/i386/efi/grub-mkimage.c? > > Not that hard, but > > * we'd better to have one grub-mkimage.c for all EFI targets > > I agree. > > > * working on binutils is even better. > > The key problem with this as I see it is that it would force people to > have a cross-compiler suite installed, at least for i386 hosts. Unless > we can magically get the default installation to include PE-support. On my debian system, objdump -i: efi-app-ia32 It's already here! The binutils issue is mainly for ia64. For i386, grub-mkimage.c works. Tristan. On i386 objcopy in binutils can convert ELF format into PE32, but application need dynamically relocate itself so that PE32 image can be loaded to any place to execute. For grub-mkimage.c application need not because grub-mkimage will generate dynamic relocate segment. Two methods is ok for me, I prefer the easier one :) thanks bibo,mao ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Scripting (IMPORTANT!)
Hollis Blanchard <[EMAIL PROTECTED]> writes: > On Thu, 2006-10-05 at 15:41 +0200, Marco Gerards wrote: >> I'm looking forwards to your ideas, questions, suggestions, criticism >> and bug reports. :-) > > How hard do you think it will be to implement all these features (and > handle the bugs)? Most of it is implemented already. Other features will be implemented. Some things are easy to implement. Like the test and expr commands. I hope I can move the iterators to modules as well. Modules are easier to maintain, because of its interfaces. But of course there are things that I do not like, when talking about maintainability: - The lexer is handcoded, I prefer a generated scanner. - Preventing memory leaks is annoying. - Perhaps more thoughts about error handling is required. > I wonder if we wouldn't be better served by a simpler scripting > language, rather than trying to emulate bash. I think it is simple already. But suggestions to make the code easier to read, increase maintainability and flexibility are always welcome. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re:%3A about %22grub.cfg%22
Title: Mail - Original Message - From: 尚涛 To: hollis Sent: 2006-10-13, 21:17:50 Subject: Re%3A about %22grub.cfg%22 hollis， Hi!At first,hanks for your reply. How exactly would you like it to be automatically generated?" I think it at least generate a sample file 'grub.cfg' which describe the commands and statements the file supports in the comment, and it should include a menuentry which boots the current system (for example:the Linux system ). 尚涛，[EMAIL PROTECTED] 2006-10-13 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re:%3A about %22grub.cfg%22
Title: Mail - Original Message - From: 尚涛 To: hollis Sent: 2006-10-13, 21:17:50 Subject: Re%3A about %22grub.cfg%22 hollis， Hi!At first,hanks for your reply. How exactly would you like it to be automatically generated?" I think it at least generate a sample file 'grub.cfg' which describe the commands and statements the file supports in the comment, and it should include a menuentry which boots the current system (for example:the Linux system ). 尚涛，[EMAIL PROTECTED] 2006-10-13 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub for ia64
On Friday 13 October 2006 10:02, bibo,mao wrote: > On i386 objcopy in binutils can convert ELF format into PE32, but > application need dynamically relocate itself so that PE32 image can be > loaded to any place to execute. For grub-mkimage.c application need not > because grub-mkimage will generate dynamic relocate segment. > Two methods is ok for me, I prefer the easier one :) Please look at my page on the wiki for details. In short, I won't throw away my code, since binutils is not enough anyway. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: how to increase commandline size (patch + changelog)
On Tuesday 10 October 2006 19:17, Jeff Chua wrote: > On Tue, 10 Oct 2006, Marco Gerards wrote: > > Hollis Blanchard <[EMAIL PROTECTED]> writes: > >> What exactly happens if we give the kernel a longer cmdline than it > >> supports? Does it just truncate, or fail to boot? > > > > It truncates. > > > >> Why not allow users to pass as much as they want, and just warn them if > >> it's >255? > > > > I am not sure what the impact is. Linux has a memory map and I assume > > the memory after the commandline is used for other things, or might be > > overwritten. > > Is it possible to "calculate" the needed offset for the exact cmdline > length user pass in to grub and set this in grub2/kern/i386/pc/startup.S, > then we don't need to worry about what the user pass in. I do not like it very much. Linux specifies how it is loaded precisely, so we should follow it carefully. Even if loadlin passes anything and it is useful for you, it is a bug feature, and I don't appreciate that way. BTW this is a kind of FAQ. I have answered the same question several times until now. All I have been saying is that you should improve Linux before changing GRUB. I thought someone took an action for this, but the specification hasn't changed AFAIK. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub and DiskOnChip devices.
On Friday 06 October 2006 21:16, Todd Denniston wrote: > when I looked through the notes in the source and the grub2 (and grub) > website I did not see anything indicating that either of the current > unpatched releases of grub could work with a DiskOnChip flash device. I do not think it works. > This was a little surprising considering there have been supposedly working > patches[1] since November 2003. Did I miss something? The patch is for GRUB Legacy but not for GRUB 2. > It looks like Okuji believed at one time[2] ilgiz had not gotten the > assignment forms done, but ilgiz later[3] indicated ilgiz had gotten the > forms in and had received FSF confirmation. Also dwmw2 indicated[4] his > assignment forms were in for his changes. Not only I believed it, but also it was the truth. He hadn't sent the paper for more than 2 years, and when he did, it was too late, since GRUB Legacy was feature-frozen then. > Are there other reasons that the patches never got included in grub? No. > Is there any reason other than the assignment forms, that the concepts (and > hopefully _some_ of the working code) from the patches can't be > incorporated into grub2? It's possible, but the code base is so different, and so somebody must make effort. If you do, I would be happy to incorporate it. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Scripting (IMPORTANT!)
On Thursday 05 October 2006 15:41, Marco Gerards wrote:
> It's also one of the features that we all have to talk about before we
> determine it will not be changed. After GRUB 2 is being used by
> everyone it will be hard, if not impossible, to make changes that make
> different GRUB 2 versions incompatible.
I agree. And I believe that GRUB should follow BASH whenever reasonable, so
that the user does not have to learn new things only for GRUB. Inventing a
new syntax is something I dislike. Also, I believe that one should write a
new module if she wants another language in GRUB, and execute it by a
command, as in GNU.
> Another thing I want to discuss soon is using "cd" and "pwd" commands
> to change the current directory instead of what we have now. I would
> like to make this change as well.
I thought the same thing before, but I didn't, because the effect of setting
the root device has a different meaning, that is, to set a boot device for
the chainloader. Besides this, the root variable is very similar to the
concept of "current working directory" in Unix. So I wouldn't object
strongly, even if you change it this way.
> =
> Variables
> =
>
> In GRUB 2 there are two types of variables. The difference is like in
> bash: the scope. Variables either have a local or global (exported)
> scope. Initially all new added variables have the local scope. By
> using the export command they can be made global.
>
> Some variables have a special purpose and will be created by GRUB.
> These are:
>
> - root: The active disk/partition (rw, global)
> - prefix: The pathname used to load grub.cfg and the modules (rw, global)
> - platform: Set to the platform, eg. EFI, IEEE1275, PCBIOS, etc. (ro,
> global) - processor: Processor architecture GRUB was compiled for, eg. PPC,
> x86 (ro, global). - debug: Print debugging messages for certain parts of
> the code, or all messages when set to all. (rw, global?)
> - pager: When set to `1', wait for a key when the bottom of the screen was
> reached.
BTW the Intel's EFI Shell uses an option to a command to enable a pager. This
way might be more convenient than a variable. Or a pipe? I think a pipe
sounds overkill, though.
>
> Menu entries
>
>
> Menu entries are added with `menuentry' (or its alias `@'). It's
> important to notice this is not a command. Because it's part of the
> scripting syntax, it can have unique features. A menuentry is like a
> function, especially because it can have arguments!
>
> Syntax: menuentry "Entry name" [arguments...] { body }
>
> Make sure the entry name is properly escaped, otherwise spaces can not
> be included and will be seen as separator. The arguments will become
> semi-variables like #1, #2, etc. These can be used so one menuentry
> can be used as a template for a lot of menuentries. This can best be
> explained with an example:
>
> (inside loop that sets i = 1...x)
> @ "Partition $i" $i { linux /vmlinuz root=/dev/hda#{1} }
>
> This will set #1 to $i (it's the first argument). The menuentry
> command is executed for i=1...9 and will generate 9 different menu
> entries. This is useful for automatic generation of menu entries.
>
> ==> Currently unimplemented: Arguments for automatic generation of
> menuentries.
> ==> Discussion: Perhaps I will change the #1 into $1, although this is
> not really a variable.
As I said before, menu entries are a special type of functions. So the
arguments must be passed as $1, $2, etc.
> =
> for
> =
>
> The for command can be used to iterate over a set of data. I don't
> like the idea of implementing this *exactly* like in bash. Personally
> I am thinking of the following syntax:
>
> Iterating over files:
> for x in (hd0,3)/foo/* ; do commands ; done
How is this different from BASH? The asterisk is interpreted as a wildcard,
and this is not a part of "for" in BASH.
>
> Error handling
>
>
> Every command can return an error value. This error value will be
> available as $?. This variable will be checked by if, while, etc. In
> scripts all parsing errors will be non fatal so the system is not left
> unbootable.
>
> Unparsable menu entries will be added, but will not be executable,
> only the editor is available.
>
> One special purpose variable $ERROR will be added. It will contain
> the error strings when $? is set to non-zero. In that case you can do
> error handling in scripts.
>
> After every command an error is printed by default. You don't want
> this to be silent, otherwise users can not detect errors. But it
> should be able to set error handling to silent because a certain
> script or function does its own error handling. This can be done by
> setting $ERRORS=0 (default it is set to 1).
>
> ==> Currently unimplemented: $ERROR, $ERRORS, a lot of this logic is
> far from perfect.
This sounds too much for me. How about supporting a subset of "set" in BASH?
For example,
Re: Scripting (IMPORTANT!)
"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes:
> On Thursday 05 October 2006 15:41, Marco Gerards wrote:
>> It's also one of the features that we all have to talk about before we
>> determine it will not be changed. After GRUB 2 is being used by
>> everyone it will be hard, if not impossible, to make changes that make
>> different GRUB 2 versions incompatible.
>
> I agree. And I believe that GRUB should follow BASH whenever reasonable, so
> that the user does not have to learn new things only for GRUB. Inventing a
> new syntax is something I dislike. Also, I believe that one should write a
> new module if she wants another language in GRUB, and execute it by a
> command, as in GNU.
Great. It is easy to add a new parser and bits and pieces of the
AST. So adding another language should be easy by design.
>> Another thing I want to discuss soon is using "cd" and "pwd" commands
>> to change the current directory instead of what we have now. I would
>> like to make this change as well.
>
> I thought the same thing before, but I didn't, because the effect of setting
> the root device has a different meaning, that is, to set a boot device for
> the chainloader. Besides this, the root variable is very similar to the
> concept of "current working directory" in Unix. So I wouldn't object
> strongly, even if you change it this way.
I think it makes more sense when scripting. I also think it is easier
for users to deal with.
[...]
>> - pager: When set to `1', wait for a key when the bottom of the screen was
>> reached.
>
> BTW the Intel's EFI Shell uses an option to a command to enable a pager. This
> way might be more convenient than a variable. Or a pipe? I think a pipe
> sounds overkill, though.
Well, I made this a variable because we wanted variables instead of
commands when possible.
>>
>> Menu entries
>>
>>
>> Menu entries are added with `menuentry' (or its alias `@'). It's
>> important to notice this is not a command. Because it's part of the
>> scripting syntax, it can have unique features. A menuentry is like a
>> function, especially because it can have arguments!
>>
>> Syntax: menuentry "Entry name" [arguments...] { body }
>>
>> Make sure the entry name is properly escaped, otherwise spaces can not
>> be included and will be seen as separator. The arguments will become
>> semi-variables like #1, #2, etc. These can be used so one menuentry
>> can be used as a template for a lot of menuentries. This can best be
>> explained with an example:
>>
>> (inside loop that sets i = 1...x)
>> @ "Partition $i" $i { linux /vmlinuz root=/dev/hda#{1} }
>>
>> This will set #1 to $i (it's the first argument). The menuentry
>> command is executed for i=1...9 and will generate 9 different menu
>> entries. This is useful for automatic generation of menu entries.
>>
>> ==> Currently unimplemented: Arguments for automatic generation of
>> menuentries.
>> ==> Discussion: Perhaps I will change the #1 into $1, although this is
>> not really a variable.
>
> As I said before, menu entries are a special type of functions. So the
> arguments must be passed as $1, $2, etc.
Well, $1, $2, etc makes more sense to me as well. But it doesn't
describe what really happens, although the user might not be concerned
with this. I will start a discussion on this if it causes problems.
>> =
>> for
>> =
>>
>> The for command can be used to iterate over a set of data. I don't
>> like the idea of implementing this *exactly* like in bash. Personally
>> I am thinking of the following syntax:
>>
>> Iterating over files:
>> for x in (hd0,3)/foo/* ; do commands ; done
>
> How is this different from BASH? The asterisk is interpreted as a wildcard,
> and this is not a part of "for" in BASH.
You removed the relevant context. Right, GRUB has no wildcard. I
don't really understand what you mean.
>>
>> Error handling
>>
>>
>> Every command can return an error value. This error value will be
>> available as $?. This variable will be checked by if, while, etc. In
>> scripts all parsing errors will be non fatal so the system is not left
>> unbootable.
>>
>> Unparsable menu entries will be added, but will not be executable,
>> only the editor is available.
>>
>> One special purpose variable $ERROR will be added. It will contain
>> the error strings when $? is set to non-zero. In that case you can do
>> error handling in scripts.
>>
>> After every command an error is printed by default. You don't want
>> this to be silent, otherwise users can not detect errors. But it
>> should be able to set error handling to silent because a certain
>> script or function does its own error handling. This can be done by
>> setting $ERRORS=0 (default it is set to 1).
>>
>> ==> Currently unimplemented: $ERROR, $ERRORS, a lot of this logic is
>> far from perfect.
>
> This sounds too much for me. How about supporting a subset of "set" in BASH?
> For examp
multiboot for PowerPC
For Xen development, I need multiboot for PowerPC. In a week or so, I will be starting this work based on Okuji-san's wiki page at http://grub.enbug.org/MultibootDraft . I just wanted to let people know in case anybody has some additional comments about it. (I haven't read the page fully yet myself.) -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot for PowerPC
I just stalk this mailing list, but I think it'd be great to turn the Multiboot specification less PC BIOS-centric. The Multiboot spec exposes various legacy structures for the x86 PC. How do you intend to work in platform specifics? Just expose the OF interface, or clone the device tree? What about non-OF systems?Slightly OT, but has any work been done to make Multiboot ia32/x64 EFI-friendly? Andrei Evgenievich Warkentin[EMAIL PROTECTED]Cell: (+1) (847) 321-15-55 On 13.10.2006, at 14:44, Hollis Blanchard wrote:For Xen development, I need multiboot for PowerPC. In a week or so, Iwill be starting this work based on Okuji-san's wiki page athttp://grub.enbug.org/MultibootDraft .I just wanted to let people know in case anybody has some additionalcomments about it. (I haven't read the page fully yet myself.)-Hollis___Grub-devel mailing listGrub-devel@gnu.orghttp://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Scripting (IMPORTANT!)
On Friday 13 October 2006 21:52, Marco Gerards wrote: > > I thought the same thing before, but I didn't, because the effect of > > setting the root device has a different meaning, that is, to set a boot > > device for the chainloader. Besides this, the root variable is very > > similar to the concept of "current working directory" in Unix. So I > > wouldn't object strongly, even if you change it this way. > > I think it makes more sense when scripting. I also think it is easier > for users to deal with. I don't know. I leave the decision to you. > > BTW the Intel's EFI Shell uses an option to a command to enable a pager. > > This way might be more convenient than a variable. Or a pipe? I think a > > pipe sounds overkill, though. > > Well, I made this a variable because we wanted variables instead of > commands when possible. Exactly. > Well, $1, $2, etc makes more sense to me as well. But it doesn't > describe what really happens, although the user might not be concerned > with this. I will start a discussion on this if it causes problems. I guess this wouldn't be a big problem, since most users wouldn't use this feature. > >> = > >> for > >> = > >> > >> The for command can be used to iterate over a set of data. I don't > >> like the idea of implementing this *exactly* like in bash. Personally > >> I am thinking of the following syntax: > >> > >> Iterating over files: > >> for x in (hd0,3)/foo/* ; do commands ; done > > > > How is this different from BASH? The asterisk is interpreted as a > > wildcard, and this is not a part of "for" in BASH. > > You removed the relevant context. Right, GRUB has no wildcard. I > don't really understand what you mean. I meant that the asterisk is not a part of a description for "for". > > This sounds too much for me. How about supporting a subset of "set" in > > BASH? For example, set -d and set +d. The default can be set -d. > > What do you mean by "this"? I assume you mean -e instead of -d? I > hope you can check what you really mean, a -d does not exist. Oops. Yes, I meant -e instead. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot for PowerPC
On Fri, 2006-10-13 at 15:06 -0500, Andrei E. Warkentin wrote: > I just stalk this mailing list, but I think it'd be great to turn the > Multiboot specification less PC BIOS-centric. The Multiboot spec > exposes various legacy structures for the x86 PC. How do you intend to > work in platform specifics? Just expose the OF interface, or clone the > device tree? What about non-OF systems? Have you read the wiki page? http://grub.enbug.org/MultibootDraft I don't intend to put any Open Firmware information into the multiboot structure, since OF will still be live when the OS is executed. > Slightly OT, but has any work been done to make Multiboot ia32/x64 > EFI-friendly? Should be the same situation I guess. -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Scripting (IMPORTANT!)
"Yoshinori K. Okuji" <[EMAIL PROTECTED]> writes: >> >> = >> >> for >> >> = >> >> >> >> The for command can be used to iterate over a set of data. I don't >> >> like the idea of implementing this *exactly* like in bash. Personally >> >> I am thinking of the following syntax: >> >> >> >> Iterating over files: >> >> for x in (hd0,3)/foo/* ; do commands ; done >> > >> > How is this different from BASH? The asterisk is interpreted as a >> > wildcard, and this is not a part of "for" in BASH. >> >> You removed the relevant context. Right, GRUB has no wildcard. I >> don't really understand what you mean. > > I meant that the asterisk is not a part of a description for "for". It's good you mention this, because it's exactly the discussion I want to start. The question here is: How do we want to deal with the `for'? In bash it iterates over all arguments. The wildcards are expanded by the shell and thus it just has a look at its arguments. The question here is, do we want to deal with wildcards? It makes the code more complex and I think there is little gain. For GRUB I think some kind of iterators are more useful. In that case you can write a module to iterate over certain data. For example over files, disks, partitions, terminals or whatever. It leaves the bash syntax, but it is more useful in our case and modular. >> > This sounds too much for me. How about supporting a subset of "set" in >> > BASH? For example, set -d and set +d. The default can be set -d. >> >> What do you mean by "this"? I assume you mean -e instead of -d? I >> hope you can check what you really mean, a -d does not exist. > > Oops. Yes, I meant -e instead. Great! Thanks. I didn't know about "set -e", so I am happy you mentioned it. I will add this feature to our set. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: multiboot for PowerPC
On 13.10.2006, at 15:55, Hollis Blanchard wrote: On Fri, 2006-10-13 at 15:06 -0500, Andrei E. Warkentin wrote: I just stalk this mailing list, but I think it'd be great to turn the Multiboot specification less PC BIOS-centric. The Multiboot spec exposes various legacy structures for the x86 PC. How do you intend to work in platform specifics? Just expose the OF interface, or clone the device tree? What about non-OF systems? Have you read the wiki page? http://grub.enbug.org/MultibootDraft I don't intend to put any Open Firmware information into the multiboot structure, since OF will still be live when the OS is executed. Ah okay, so just store the OF entry pointer or EFI system table with key-value. Okay. That makes sense. Slightly OT, but has any work been done to make Multiboot ia32/x64 EFI-friendly? Should be the same situation I guess. -Hollis ___ 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: multiboot for PowerPC
On Fri, 2006-10-13 at 16:18 -0500, Andrei E. Warkentin wrote: > > > I don't intend to put any Open Firmware information into the > multiboot > > structure, since OF will still be live when the OS is executed. > > Ah okay, so just store the OF entry pointer or EFI system table with > key-value. Okay. That makes sense. Actually, even better would be to preserve it just as if firmware had loaded the OS directly. For PowerPC, that means maintaining the entry vector in GPR5. This way, OSs don't need to know anything about multiboot at all (the embedded multiboot header is another conversation). -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] generic ELF loading
This patch adds generic ELF loading infrastructure for both 32-bit and
64-bit ELF. It provides an "iterate" function for program headers, and a
"load" function for convenience.
I have converted the PowerPC Linux loader to use this infrastructure
(see next mail), and possibly the i386 multiboot loader as well (though
I will need others to test it). The module loader looks a little more
annoying because it actually loads *sections*, not segments.
I will be away next week but intend to commit this soon after, so please
review.
This code is literally duplicated, once for 32-bit and once for 64-bit.
I'm trying to come up with a better way of doing that, and I'm
considering something like this:
elf32.c:
#define Elf_Ehdr Elf32_Ehdr
#define Elf_Phdr Elf32_Phdr
#include "elfclass.c"
elf64.c:
#define Elf_Ehdr Elf64_Ehdr
#define Elf_Phdr Elf64_Phdr
#include "elfclass.c"
If you strongly object to #including C files, or have a better way of
doing this, please speak up.
-Hollis
diff -r b53dfa2812ad include/grub/elfload.h
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/include/grub/elfload.hFri Oct 13 16:23:22 2006 -0500
@@ -0,0 +1,57 @@
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef GRUB_ELFLOAD_HEADER
+#define GRUB_ELFLOAD_HEADER1
+
+#include
+#include
+#include
+#include
+#include
+
+struct grub_elf_file
+{
+ grub_file_t file;
+ union {
+Elf64_Ehdr ehdr64;
+Elf32_Ehdr ehdr32;
+ } ehdr;
+ void *phdrs;
+};
+typedef struct grub_elf_file *grub_elf_t;
+
+grub_elf_t EXPORT_FUNC(grub_elf_open) (const char *name);
+grub_err_t EXPORT_FUNC(grub_elf_close) (grub_elf_t elf);
+
+int EXPORT_FUNC(grub_elf_is_elf32) (grub_elf_t elf);
+grub_err_t EXPORT_FUNC(grub_elf32_phdr_iterate) (grub_elf_t elf,
+int (*hook) (grub_elf_t, Elf32_Phdr *, void *),
+void *hook_arg);
+grub_err_t EXPORT_FUNC(grub_elf32_load) (grub_elf_t elf,
+int (*) (Elf32_Phdr *));
+
+int EXPORT_FUNC(grub_elf_is_elf64) (grub_elf_t elf);
+grub_err_t EXPORT_FUNC(grub_elf64_phdr_iterate) (grub_elf_t elf,
+int (*hook) (grub_elf_t, Elf64_Phdr *, void *),
+void *hook_arg);
+grub_err_t EXPORT_FUNC(grub_elf64_load) (grub_elf_t elf,
+int (*) (Elf64_Phdr *));
+
+#endif /* ! GRUB_ELFLOAD_HEADER */
diff -r b53dfa2812ad kern/elf.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/kern/elf.cFri Oct 13 16:23:22 2006 -0500
@@ -0,0 +1,280 @@
+/* elf.c - load ELF files */
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Check if EHDR is a valid ELF header. */
+static grub_err_t
+grub_elf_check_header (grub_elf_t elf)
+{
+ Elf32_Ehdr *e = &elf->ehdr.ehdr32;
+
+ if (e->e_ident[EI_MAG0] != ELFMAG0
+ || e->e_ident[EI_MAG1] != ELFMAG1
+ || e->e_ident[EI_MAG2] != ELFMAG2
+ || e->e_ident[EI_MAG3] != ELFMAG3
+ || e->e_ident[EI_VERSION] != EV_CURRENT
+ || e->e_version != EV_CURRENT)
+return grub_error (GRUB_ERR_BAD_OS, "invalid arch independent ELF magic");
+
+ return GRUB_ERR_NONE;
+}
+
+grub_err_t
+grub_elf_close (grub_elf_t elf)
+{
+ grub_file_t file = elf->file;
+
+ grub_free (elf->phdrs);
+ grub_free (elf);
+
+
Re: [PATCH] ppc64 Linux ELF loader
This patch converts the PowerPC Linux loader to use the ELF
infrastructure in the last patch, which gives us 64-bit ELF support. You
can see examples of how I'm using the ELF "iterate" and "load"
functions.
-Hollis
diff -r b7b3f308a91d include/grub/types.h
--- a/include/grub/types.h Fri Oct 13 13:50:22 2006 -0500
+++ b/include/grub/types.h Fri Oct 13 13:50:22 2006 -0500
@@ -22,6 +22,8 @@
#include
#include
+
+#define __unused __attribute__ ((unused))
#ifdef GRUB_UTIL
# define GRUB_CPU_SIZEOF_VOID_PSIZEOF_VOID_P
diff -r b7b3f308a91d loader/powerpc/ieee1275/linux.c
--- a/loader/powerpc/ieee1275/linux.c Fri Oct 13 13:50:22 2006 -0500
+++ b/loader/powerpc/ieee1275/linux.c Fri Oct 13 16:17:32 2006 -0500
@@ -19,6 +19,7 @@
*/
#include
+#include
#include
#include
#include
@@ -27,6 +28,9 @@
#include
#include
+#define ELF32_LOADMASK (0xc000UL)
+#define ELF64_LOADMASK (0xc000ULL)
+
static grub_dl_t my_mod;
static int loaded;
@@ -97,53 +101,17 @@ grub_linux_unload (void)
return err;
}
-void
-grub_rescue_cmd_linux (int argc, char *argv[])
-{
- grub_file_t file = 0;
- Elf32_Ehdr ehdr;
- Elf32_Phdr *phdrs = 0;
- int i;
- int offset = 0;
- grub_addr_t entry;
+static grub_err_t
+grub_linux_load32 (grub_elf_t elf)
+{
+ Elf32_Addr entry;
+ Elf32_Addr segments_start = (Elf32_Addr) -1;
+ Elf32_Addr segments_end = 0;
int found_addr = 0;
- int size;
- char *dest;
-
- grub_dl_ref (my_mod);
-
- if (argc == 0)
-{
- grub_error (GRUB_ERR_BAD_ARGUMENT, "no kernel specified");
- goto fail;
-}
-
- file = grub_file_open (argv[0]);
- if (! file)
-goto fail;
-
- if (grub_file_read (file, (char *) &ehdr, sizeof (ehdr)) != sizeof (ehdr))
-{
- grub_error (GRUB_ERR_READ_ERROR, "cannot read the linux elf header");
- goto fail;
-}
-
- if (grub_dl_check_header (&ehdr, sizeof(ehdr)))
-{
- grub_error (GRUB_ERR_UNKNOWN_OS, "No valid ELF header found");
- goto fail;
-}
-
- if (ehdr.e_type != ET_EXEC)
-{
- grub_error (GRUB_ERR_UNKNOWN_OS,
- "This ELF file is not of the right type\n");
- goto fail;
-}
-
- /* Read the sections. */
- entry = ehdr.e_entry;
- if (entry == 0xc000)
+
+ /* Linux's entry point incorrectly contains a virtual address. */
+ entry = elf->ehdr.ehdr32.e_entry & ~ELF32_LOADMASK;
+ if (entry == 0)
{
entry = 0x0140;
vmlinux = 1;
@@ -151,26 +119,23 @@ grub_rescue_cmd_linux (int argc, char *a
else
vmlinux = 0;
- phdrs = (Elf32_Phdr *) grub_malloc (ehdr.e_phnum * ehdr.e_phentsize);
- grub_file_read (file, (void *) phdrs, ehdr.e_phnum * ehdr.e_phentsize);
-
- /* Release the previously used memory. */
- grub_loader_unset ();
-
- /* Determine the amount of memory that is required. */
- linux_size = 0;
- for (i = 0; i < ehdr.e_phnum; i++)
-{
- Elf32_Phdr *phdr = phdrs + i;
- /* XXX: Is this calculation correct? */
- linux_size += phdr->p_memsz + phdr->p_filesz;
-}
-
- /* Reserve memory for the kernel. */
- linux_size += 0x10;
-
- /* For some vmlinux kernels the address set above won't work. Just
- try some other addresses just like yaboot does. */
+ /* Run through the program headers to calculate the total memory size we
+ * should claim. */
+ auto int calcsize (grub_elf_t _elf, Elf32_Phdr *phdr, void *_arg);
+ int calcsize (grub_elf_t __unused _elf, Elf32_Phdr *phdr, void __unused
*_arg)
+{
+ if (phdr->p_paddr < segments_start)
+ segments_start = phdr->p_paddr;
+ if (phdr->p_paddr + phdr->p_memsz > segments_end)
+ segments_end = phdr->p_paddr + phdr->p_memsz;
+ return 1;
+}
+ grub_elf32_phdr_iterate (elf, calcsize, 0);
+ linux_size = segments_end - segments_start + 0x10;
+
+ /* On some systems, firmware occupies the memory we're trying to use.
+ * Happily, Linux can be loaded anywhere (it relocates itself). Iterate
+ * until we find an open area. */
for (linux_addr = entry; linux_addr < entry + 200 * 0x10; linux_addr +=
0x10)
{
grub_dprintf ("loader", "Attempting to claim at 0x%x, size 0x%x.\n",
@@ -179,42 +144,120 @@ grub_rescue_cmd_linux (int argc, char *a
if (found_addr != -1)
break;
}
-
if (found_addr == -1)
-{
- grub_error (GRUB_ERR_OUT_OF_MEMORY, "Can not claim memory");
- goto fail;
-}
- entry = linux_addr;
-
- /* Load every loadable segment in memory. */
- for (i = 0; i < ehdr.e_phnum; i++)
-{
- Elf32_Phdr *phdr = phdrs + i;
-
- if (phdr->p_type == PT_LOAD)
- {
- void *segment_addr = ((char *) entry) + offset;
-
- if (grub_file_seek (file, phdr->p_offset) == (grub_off_t) -1)
- {
- grub_error (GRUB_ERR_BAD_OS, "Invalid offset in program header");
- goto fail;
- }
-
- grub_dprintf ("loader", "Loading segment %d at %p, size 0x%x\n", i,
-
RE: [PATCH] generic ELF loading
I do not know whether it is possible to add one element in structure
grub_elf_file structure to identify ELF type (ELFCLASS32/ELFCLASS64)
and ELF machine type, this element can be set at function grub_elf_open.
Thanks
Bibo,mao
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Hollis
>Blanchard
>Sent: 2006年10月14日 6:38
>To: grub-devel
>Subject: [PATCH] generic ELF loading
>
>This patch adds generic ELF loading infrastructure for both 32-bit and
>64-bit ELF. It provides an "iterate" function for program headers, and a
>"load" function for convenience.
>
>I have converted the PowerPC Linux loader to use this infrastructure
>(see next mail), and possibly the i386 multiboot loader as well (though
>I will need others to test it). The module loader looks a little more
>annoying because it actually loads *sections*, not segments.
>
>I will be away next week but intend to commit this soon after, so please
>review.
>
>This code is literally duplicated, once for 32-bit and once for 64-bit.
>I'm trying to come up with a better way of doing that, and I'm
>considering something like this:
>
>elf32.c:
>#define Elf_Ehdr Elf32_Ehdr
>#define Elf_Phdr Elf32_Phdr
>#include "elfclass.c"
>
>elf64.c:
>#define Elf_Ehdr Elf64_Ehdr
>#define Elf_Phdr Elf64_Phdr
>#include "elfclass.c"
>
>If you strongly object to #including C files, or have a better way of
>doing this, please speak up.
>
>-Hollis
>
>diff -r b53dfa2812ad include/grub/elfload.h
>--- /dev/null Thu Jan 01 00:00:00 1970 +
>+++ b/include/grub/elfload.h Fri Oct 13 16:23:22 2006 -0500
>@@ -0,0 +1,57 @@
>+/*
>+ * GRUB -- GRand Unified Bootloader
>+ * Copyright (C) 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
>+ *
>+ * This program is free software; you can redistribute it and/or modify
>+ * it under the terms of the GNU General Public License as published by
>+ * the Free Software Foundation; either version 2 of the License, or
>+ * (at your option) any later version.
>+ *
>+ * This program is distributed in the hope that it will be useful,
>+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
>+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>+ * GNU General Public License for more details.
>+ *
>+ * You should have received a copy of the GNU General Public License
>+ * along with this program; if not, write to the Free Software
>+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
>+ */
>+
>+#ifndef GRUB_ELFLOAD_HEADER
>+#define GRUB_ELFLOAD_HEADER 1
>+
>+#include
>+#include
>+#include
>+#include
>+#include
>+
>+struct grub_elf_file
>+{
>+ grub_file_t file;
>+ union {
>+Elf64_Ehdr ehdr64;
>+Elf32_Ehdr ehdr32;
>+ } ehdr;
>+ void *phdrs;
>+};
>+typedef struct grub_elf_file *grub_elf_t;
>+
>+grub_elf_t EXPORT_FUNC(grub_elf_open) (const char *name);
>+grub_err_t EXPORT_FUNC(grub_elf_close) (grub_elf_t elf);
>+
>+int EXPORT_FUNC(grub_elf_is_elf32) (grub_elf_t elf);
>+grub_err_t EXPORT_FUNC(grub_elf32_phdr_iterate) (grub_elf_t elf,
>+ int (*hook) (grub_elf_t, Elf32_Phdr *, void *),
>+ void *hook_arg);
>+grub_err_t EXPORT_FUNC(grub_elf32_load) (grub_elf_t elf,
>+ int (*) (Elf32_Phdr *));
>+
>+int EXPORT_FUNC(grub_elf_is_elf64) (grub_elf_t elf);
>+grub_err_t EXPORT_FUNC(grub_elf64_phdr_iterate) (grub_elf_t elf,
>+ int (*hook) (grub_elf_t, Elf64_Phdr *, void *),
>+ void *hook_arg);
>+grub_err_t EXPORT_FUNC(grub_elf64_load) (grub_elf_t elf,
>+ int (*) (Elf64_Phdr *));
>+
>+#endif /* ! GRUB_ELFLOAD_HEADER */
>diff -r b53dfa2812ad kern/elf.c
>--- /dev/null Thu Jan 01 00:00:00 1970 +
>+++ b/kern/elf.c Fri Oct 13 16:23:22 2006 -0500
>@@ -0,0 +1,280 @@
>+/* elf.c - load ELF files */
>+/*
>+ * GRUB -- GRand Unified Bootloader
>+ * Copyright (C) 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
>+ *
>+ * This program is free software; you can redistribute it and/or modify
>+ * it under the terms of the GNU General Public License as published by
>+ * the Free Software Foundation; either version 2 of the License, or
>+ * (at your option) any later version.
>+ *
>+ * This program is distributed in the hope that it will be useful,
>+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
>+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>+ * GNU General Public License for more details.
>+ *
>+ * You should have received a copy of the GNU General Public License
>+ * along with this program; if not, write to the Free Software
>+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
>+ */
>+
>+#include
>+#include
>+#include
>+#include
>+#include
>+#include
>+
>+/* Check if EHDR is a valid ELF header. */
>+static grub_err_t
>+grub_elf_check_header (grub_elf_t elf)
>+{
>
