Re: Testing on PowerMac G4
On Sat, Jan 05, 2008 at 02:27:34AM +0100, Yoshinori K. Okuji wrote: > > Anyway, there is no reason that you shouldn't write a detailed description in > ChangeLog. Indeed, I myself sometimes do that, when I make a big change or > something hard to understand. Good enough for me.. I'll take it into account. -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Fri, Jan 04, 2008 at 09:10:03PM -0500, Pavel Roskin wrote: > On Fri, 2008-01-04 at 21:37 +0100, Robert Millan wrote: > > > If you want to confirm that it's grub-mkimage's fault, you can try booting > > kernel.elf directly. In theory it should give you a rescue prompt. > > That's what it does. And that's what we have been discussing closer to > the bottom :-) Yeah, but it never hurts to be sure! > > > In fact, the image doesn't even survive > > > simple objcopy intact. "objcopy grubof.modules grubof.modules1" > > > produces a file 208 bytes long. > > > > What is grubof.modules ? I never heard of it. > > That's the suggested name for the grub-mkimage output on PowerPC, > according to http://grub.enbug.org/TestingOnPowerPC I found this in NEWS: "* Use the filename "kernel.elf" instead of "grubof" on ieee1275." Sounds like a deprecated name. -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Sat, Jan 05, 2008 at 02:45:41AM +0100, Yoshinori K. Okuji wrote: > On Friday 04 January 2008 21:37, Robert Millan wrote: > > > A quick look into util/elf/grub-mkimage.c finds "Don't bother preserving > > > the section headers". I don't even know if the problem is specifically > > > with the section headers or with something else. Perhaps > > > util/elf/grub-mkimage.c should be rewritten as a linker script, or maybe > > > it should use the BFD library that comes with binutils. I'm optimistic > > > about the linker script, since all we need is essentially linking. > > > > There's another [1] outstanding problem with elf/grub-mkimage.c: > > > > http://lists.gnu.org/archive/html/grub-devel/2007-10/msg00056.html > > > > I think what you propose is a good idea. It sounds odd that we have to > > reimplement ELF handling when another GNU project already has. But I don't > > know how the GRUB maintainers think about it. > > > > [1] or, perhaps, it's the same problem? > > I object to using a linker, since it is more odd that the user must install > development tools to just install GRUB. Distributors could push GNU ld from development binutils package to a separate one that is part of their base system. This happened already in Debian (and derivatives, gee) for gnupg and gpgv (since apt-get started using them for archive verification). > About BFD, the old discussion was that it made the binary size bloated, thus > didn't fit into a small disk or initrd or whatever, so it was not convenient > for installers. I don't know if the same discussion can apply nowadays, since > most people install operating systems by CD or DVD, memory size is plenty, > etc. I don't know about others, but Debian (and, yes, derivatives..) doesn't put grub-mkimage in the initrd. What is put is a script that will install standard GRUB package in the target chroot, and use that directly. I think using BFD is a good idea. > Especially if this is only for OpenFirmware platforms, I don't believe > that anybody cares. And LinuxBIOS ! And Xbox if we ever support it (I haven't managed to boot code in it yet, but it works with ELF). -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Saturday 05 January 2008 03:02, Pavel Roskin wrote: > On Sat, 2008-01-05 at 02:27 +0100, Yoshinori K. Okuji wrote: > > On Thursday 03 January 2008 16:28, Pavel Roskin wrote: > > > >> Linux style description. The first line is the synopsis. If it > > > >> doesn't fit 72 characters, the patch is a candidate for splitting. > > > >> Then an empty line. Then a more detailed description of the patch, > > > >> including the motivation behind the changes. The list of the > > > >> affected files can be generated by the version control system. > > > > > > > > Looks good. But I guess you'll have to convince Marco and Okuji > > > > about this :-) > > > > > > Sure, it's in my TODO list :) > > > > I do not think automatically generated logs can be as precise as being > > made by human. > > > > Anyway, there is no reason that you shouldn't write a detailed > > description in ChangeLog. Indeed, I myself sometimes do that, when I make > > a big change or something hard to understand. > > We are talking about a changeset from 2007-02-21 (the earliest of them), > where the ChangeLog entry has the usual "calculate this" and "rename > this to that". It took me hours of experiments to figure out that the > intention was to load the core image and the modules much lower in the > memory. Sure, it looks trivial when explained. > > And by the way, a trivial change that doesn't modify anything as > fundamental as memory layout could be described in very similar terms. > There is no way to see how profound changes are and whether they are > relevant to the observed problems. You are right, but this is nothing with ChangeLog itself. If one did not write a good commit message, the same thing happens with any kind of system. > Detailed descriptions may be useful in many cases, but in my opinion, > they should be secondary to high level descriptions. Huh? You only think about the technical aspect. Note that ChangeLog is not only for technical purpose. http://www.gnu.org/prep/maintain/html_node/Legally-Significant.html#Legally-Significant Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Fri, 2008-01-04 at 21:37 +0100, Robert Millan wrote: > If you want to confirm that it's grub-mkimage's fault, you can try booting > kernel.elf directly. In theory it should give you a rescue prompt. That's what it does. And that's what we have been discussing closer to the bottom :-) > > In fact, the image doesn't even survive > > simple objcopy intact. "objcopy grubof.modules grubof.modules1" > > produces a file 208 bytes long. > > What is grubof.modules ? I never heard of it. That's the suggested name for the grub-mkimage output on PowerPC, according to http://grub.enbug.org/TestingOnPowerPC Yes, it's long and misleading. Maybe it should be called grub.elf or something. I'm usually good at inventing new names, but I have no good ideas this time :-) > Wait, that would be EACCES in Linux errno codes. In GRUB, grub_errno > 13 means GRUB_ERR_UNKNOWN_DEVICE (at the time of writing; there isn't a > stable ABI for this afaik). Thanks, that explains something! > If grub_errno was set you should've seen an error message somewhere. It > seems there's something wrong in our error handling. :-/ I agree. > I would really check the GRUB_IEEE1275_FLAG_NO_PARTITION_0 issue. It was just > a guess, but it smells really badly :-) I'll have a look. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Sat, 2008-01-05 at 02:27 +0100, Yoshinori K. Okuji wrote: > On Thursday 03 January 2008 16:28, Pavel Roskin wrote: > > >> Linux style description. The first line is the synopsis. If it > > >> doesn't fit 72 characters, the patch is a candidate for splitting. > > >> Then an empty line. Then a more detailed description of the patch, > > >> including the motivation behind the changes. The list of the affected > > >> files can be generated by the version control system. > > > > > > Looks good. But I guess you'll have to convince Marco and Okuji > > > about this :-) > > > > Sure, it's in my TODO list :) > > I do not think automatically generated logs can be as precise as being made > by > human. > > Anyway, there is no reason that you shouldn't write a detailed description in > ChangeLog. Indeed, I myself sometimes do that, when I make a big change or > something hard to understand. We are talking about a changeset from 2007-02-21 (the earliest of them), where the ChangeLog entry has the usual "calculate this" and "rename this to that". It took me hours of experiments to figure out that the intention was to load the core image and the modules much lower in the memory. Sure, it looks trivial when explained. And by the way, a trivial change that doesn't modify anything as fundamental as memory layout could be described in very similar terms. There is no way to see how profound changes are and whether they are relevant to the observed problems. Detailed descriptions may be useful in many cases, but in my opinion, they should be secondary to high level descriptions. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Friday 04 January 2008 21:37, Robert Millan wrote: > > A quick look into util/elf/grub-mkimage.c finds "Don't bother preserving > > the section headers". I don't even know if the problem is specifically > > with the section headers or with something else. Perhaps > > util/elf/grub-mkimage.c should be rewritten as a linker script, or maybe > > it should use the BFD library that comes with binutils. I'm optimistic > > about the linker script, since all we need is essentially linking. > > There's another [1] outstanding problem with elf/grub-mkimage.c: > > http://lists.gnu.org/archive/html/grub-devel/2007-10/msg00056.html > > I think what you propose is a good idea. It sounds odd that we have to > reimplement ELF handling when another GNU project already has. But I don't > know how the GRUB maintainers think about it. > > [1] or, perhaps, it's the same problem? I object to using a linker, since it is more odd that the user must install development tools to just install GRUB. About BFD, the old discussion was that it made the binary size bloated, thus didn't fit into a small disk or initrd or whatever, so it was not convenient for installers. I don't know if the same discussion can apply nowadays, since most people install operating systems by CD or DVD, memory size is plenty, etc. Especially if this is only for OpenFirmware platforms, I don't believe that anybody cares. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Thursday 03 January 2008 16:28, Pavel Roskin wrote: > >> Linux style description. The first line is the synopsis. If it > >> doesn't fit 72 characters, the patch is a candidate for splitting. > >> Then an empty line. Then a more detailed description of the patch, > >> including the motivation behind the changes. The list of the affected > >> files can be generated by the version control system. > > > > Looks good. But I guess you'll have to convince Marco and Okuji > > about this :-) > > Sure, it's in my TODO list :) I do not think automatically generated logs can be as precise as being made by human. Anyway, there is no reason that you shouldn't write a detailed description in ChangeLog. Indeed, I myself sometimes do that, when I make a big change or something hard to understand. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Fri, Jan 04, 2008 at 01:26:59PM -0500, Pavel Roskin wrote: > > > > AFAICT, it can only happen in three ways: > > > > 1- The firmware doesn't like GRUB image, and aborts with bogus errors > > before > > transferring control to GRUB. You can easily tell this appart by checking > > for early "Welcome to GRUB" message. > > I'm quite sure now that it's the case. That's how it looks on the > surface, I just was extra cautious before I had a chance to learn more > about OpenFirmware and the GRUB code. > > Not only there is no "Welcome to GRUB" message, but the screen is not > erased and remains black on white. "CLAIM failed" is followed by the > OpenFirmware prompt. There are no messages that the execution was > interrupted, which would appear in other failure cases. > > I tried to convert grub-mkimage output to the binary format, and found > that objcopy doesn't like it. If you want to confirm that it's grub-mkimage's fault, you can try booting kernel.elf directly. In theory it should give you a rescue prompt. > In fact, the image doesn't even survive > simple objcopy intact. "objcopy grubof.modules grubof.modules1" > produces a file 208 bytes long. What is grubof.modules ? I never heard of it. > We just cannot expect OpenFirmware to process invalid ELF files. It can > be looking for the section headers and finding non-zero data is the gap > is not wide enough. It can be just anything. > > A quick look into util/elf/grub-mkimage.c finds "Don't bother preserving > the section headers". I don't even know if the problem is specifically > with the section headers or with something else. Perhaps > util/elf/grub-mkimage.c should be rewritten as a linker script, or maybe > it should use the BFD library that comes with binutils. I'm optimistic > about the linker script, since all we need is essentially linking. There's another [1] outstanding problem with elf/grub-mkimage.c: http://lists.gnu.org/archive/html/grub-devel/2007-10/msg00056.html I think what you propose is a good idea. It sounds odd that we have to reimplement ELF handling when another GNU project already has. But I don't know how the GRUB maintainers think about it. [1] or, perhaps, it's the same problem? > > > There is a possibility that grub_errno remains set to some error. > > > > Well, that's easy to tell appart with some printfs. > > What I see is the last invocation of grub_ofdisk_open() has grub_errno > set to 13 (EACCESS) throughout the code. Wait, that would be EACCES in Linux errno codes. In GRUB, grub_errno 13 means GRUB_ERR_UNKNOWN_DEVICE (at the time of writing; there isn't a stable ABI for this afaik). If grub_errno was set you should've seen an error message somewhere. It seems there's something wrong in our error handling. :-/ > A quote from the glibc manual: > > These functions do not change `errno' when they succeed; thus, the value > of `errno' after a successful call is not necessarily zero, and you > should not use `errno' to determine _whether_ a call failed. The proper > way to do that is documented for each function. _If_ the call failed, > you can examine `errno'. > > grub_ofdisk_open() is in direct violation of that rule. The execution > can reach the "fail:" label without having failed anywhere, yet the code > returns grub_errno unconditionally. Yeah, would be nice if functions had their behaviour more similar to Glibc equivalents. I'm not sure how much of a "policy" is this in GRUB, though. > That's not to negate your findings, of course. I would really check the GRUB_IEEE1275_FLAG_NO_PARTITION_0 issue. It was just a guess, but it smells really badly :-) -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Fri, 2008-01-04 at 13:32 +0100, Robert Millan wrote: > On Thu, Jan 03, 2008 at 11:23:01AM -0500, Pavel Roskin wrote: > > >Why? Does the firmware impose this restriction, or is it GRUB itself that > > >gets confused? > > > > I wish I knew it. 0x7000 is not OK, 0x8000 is OK. Less granularity > > makes no sense since the value is aligned at the 0x1000 boundary. > > AFAICT, it can only happen in three ways: > > 1- The firmware doesn't like GRUB image, and aborts with bogus errors before > transferring control to GRUB. You can easily tell this appart by checking > for early "Welcome to GRUB" message. I'm quite sure now that it's the case. That's how it looks on the surface, I just was extra cautious before I had a chance to learn more about OpenFirmware and the GRUB code. Not only there is no "Welcome to GRUB" message, but the screen is not erased and remains black on white. "CLAIM failed" is followed by the OpenFirmware prompt. There are no messages that the execution was interrupted, which would appear in other failure cases. I tried to convert grub-mkimage output to the binary format, and found that objcopy doesn't like it. In fact, the image doesn't even survive simple objcopy intact. "objcopy grubof.modules grubof.modules1" produces a file 208 bytes long. Moreover, "objdump -h grubof.modules" doesn't show any sections at all, whereas "objdump -p grubof.modules" shows the segments. It seems to me that grub-mkimage produces something that looks like and ELF file and the first glance, but is not a valid ELF file. I can reproduce this problem with linuxbios images on i386. We just cannot expect OpenFirmware to process invalid ELF files. It can be looking for the section headers and finding non-zero data is the gap is not wide enough. It can be just anything. A quick look into util/elf/grub-mkimage.c finds "Don't bother preserving the section headers". I don't even know if the problem is specifically with the section headers or with something else. Perhaps util/elf/grub-mkimage.c should be rewritten as a linker script, or maybe it should use the BFD library that comes with binutils. I'm optimistic about the linker script, since all we need is essentially linking. > > There is a possibility that grub_errno remains set to some error. > > Well, that's easy to tell appart with some printfs. What I see is the last invocation of grub_ofdisk_open() has grub_errno set to 13 (EACCESS) throughout the code. It's never unset by any successful operations. I think some filesystem module may be resetting grub_errno to 0. It's strange that I don't even see EACCESS in the code. A quote from the glibc manual: These functions do not change `errno' when they succeed; thus, the value of `errno' after a successful call is not necessarily zero, and you should not use `errno' to determine _whether_ a call failed. The proper way to do that is documented for each function. _If_ the call failed, you can examine `errno'. grub_ofdisk_open() is in direct violation of that rule. The execution can reach the "fail:" label without having failed anywhere, yet the code returns grub_errno unconditionally. That's not to negate your findings, of course. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Fri, Jan 04, 2008 at 01:32:24PM +0100, Robert Millan wrote: > (we already work this out mostly by heuristics e.g. see my commit in > 2007-10-07). Erm sorry, this part is not accurate. What I mean is that we use heuristics when firmware is buggy and its /memory/available OFW path doesn't represent actual memory availability. This is probably the case here. -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Thu, Jan 03, 2008 at 11:23:01AM -0500, Pavel Roskin wrote: > >Why? Does the firmware impose this restriction, or is it GRUB itself that > >gets confused? > > I wish I knew it. 0x7000 is not OK, 0x8000 is OK. Less granularity > makes no sense since the value is aligned at the 0x1000 boundary. AFAICT, it can only happen in three ways: 1- The firmware doesn't like GRUB image, and aborts with bogus errors before transferring control to GRUB. You can easily tell this appart by checking for early "Welcome to GRUB" message. 2- The change in layout makes GRUB issue different parameters in its claim requests, which the firmware doesn't like. I'd verify that the change you added by setting up this 0x8000 gap propagates as a change in the parameters passed to claim requests (grub_ieee1275_claim() invokation), and if this is so, try to determine what is it in the claim request that it doesn't like (we already work this out mostly by heuristics e.g. see my commit in 2007-10-07). 3- Some twisted mind in Apple decided to add a tilt flag that is activated under some circumstances and makes claim requests fail afterwards, thereby confusing free software developers. I hope this is not the case :-) > >Can we make this work per inclusion rather than exclusion? The names > >of needed segments are well-known, right? > > Segments don't have names AFAIK. Sections have names. Ah, right. Sorry, I get easily confused about ELF stuff. > >It might be simpler than this. If you check what is the code flow between > >those two: > > > >disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00. > >kern/disk.c:299: Opening `ide1/disk' failed. > > > >that'll give more details. > > There is a possibility that grub_errno remains set to some error. Well, that's easy to tell appart with some printfs. One thing that makes me suspicious is the ":0" bit. We already found two brands of firmware that have their own way of understanding what :0 means. Maybe this is the same as GRUB_IEEE1275_FLAG_NO_PARTITION_0 ? Btw, one thing I find very disturbing about GRUB_IEEE1275_FLAG_NO_PARTITION_0, is that its description in ieee1275.h says this is an Apple bug, but the code that is supposed to initialise this flag is only targetted at SmartFirmware. Now THAT is suspicious :-) -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
Quoting Robert Millan <[EMAIL PROTECTED]>: On Thu, Jan 03, 2008 at 10:28:46AM -0500, Pavel Roskin wrote: Quoting Robert Millan <[EMAIL PROTECTED]>: >>The module base address is calculated separately in kernel.elf and in >>grub-mkimage. kernel.elf uses the "_end" symbol, whereas grub-mkimage >>looks for the ELF segment with the highest end address. > >Ok, so you mean this setting: > > phdr->p_vaddr = grub_host_to_target32 (modbase); > phdr->p_paddr = grub_host_to_target32 (modbase); > >is not what it's used to calculate _end ? I can answer it now. No, it's not used to calculate _end, it needs to be incremented separately. OK, it turns out the values of _end actually match, so it's not a problem. It turns out there needs to be a gap between _end and the module base. 16k (0x4000) is not enough. 32k (0x8000) is enough. Why? Does the firmware impose this restriction, or is it GRUB itself that gets confused? I wish I knew it. 0x7000 is not OK, 0x8000 is OK. Less granularity makes no sense since the value is aligned at the 0x1000 boundary. This might differ from the init.c counterpart. There's an ALIGN_UP just a few lines above, if you set it to: modbase = ALIGN_UP(grub_end + 0x8000, GRUB_MOD_ALIGN); both alignment and 0x8000 gap are still garanteed, without claiming more space than necessary. That is, if it really is a gap that you need :-) Thanks, that would be safer indeed, although it makes no difference for the values divisible by 0x1000. Can we make this work per inclusion rather than exclusion? The names of needed segments are well-known, right? Segments don't have names AFAIK. Sections have names. But anyway, it should be possible to recognize what we need. On the other hand, "work per inclusion" would make me nervous about breaking other architectures. We need to figure out why the extra gap is needed. Maybe something doesn't get counted. Yep. How did you find that an extra gap solves the problem? I started with the original boundary at 0x30, then I tried 0x3, then _end+0xb000 (_end is something like 0x2496c), then _end+0x1000 and so on, until I found that 0x7000 is not enough and 0x8000 is enough. It might be simpler than this. If you check what is the code flow between those two: disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00. kern/disk.c:299: Opening `ide1/disk' failed. that'll give more details. There is a possibility that grub_errno remains set to some error. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Thu, Jan 03, 2008 at 10:28:46AM -0500, Pavel Roskin wrote:
> Quoting Robert Millan <[EMAIL PROTECTED]>:
>
> >>The module base address is calculated separately in kernel.elf and in
> >>grub-mkimage. kernel.elf uses the "_end" symbol, whereas grub-mkimage
> >>looks for the ELF segment with the highest end address.
> >
> >Ok, so you mean this setting:
> >
> > phdr->p_vaddr = grub_host_to_target32 (modbase);
> > phdr->p_paddr = grub_host_to_target32 (modbase);
> >
> >is not what it's used to calculate _end ?
>
> OK, it turns out the values of _end actually match, so it's not a problem.
>
> It turns out there needs to be a gap between _end and the module base.
> 16k (0x4000) is not enough. 32k (0x8000) is enough.
Why? Does the firmware impose this restriction, or is it GRUB itself that
gets confused?
> This patch against the current CVS version fixes loading:
>
> diff --git a/kern/powerpc/ieee1275/init.c b/kern/powerpc/ieee1275/init.c
> index 4727d7d..d2fa980 100644
> --- a/kern/powerpc/ieee1275/init.c
> +++ b/kern/powerpc/ieee1275/init.c
> @@ -231,5 +231,5 @@ grub_get_rtc (void)
> grub_addr_t
> grub_arch_modules_addr (void)
> {
> - return ALIGN_UP(_end, GRUB_MOD_ALIGN);
> + return ALIGN_UP(_end + 0x8000, GRUB_MOD_ALIGN);
> }
> diff --git a/util/elf/grub-mkimage.c b/util/elf/grub-mkimage.c
> index 9e44af1..c39717a 100644
> --- a/util/elf/grub-mkimage.c
> +++ b/util/elf/grub-mkimage.c
> @@ -228,6 +228,7 @@ add_segments (char *dir, FILE *out, int chrp, char
> *mods[])
>phdr->p_offset = grub_host_to_target32 (ALIGN_UP
> (grub_util_get_fp_size (out),
> sizeof (long)));
>
> + modbase += 0x8000;
>load_modules (modbase, phdr, dir, mods, out);
> }
This might differ from the init.c counterpart. There's an ALIGN_UP just
a few lines above, if you set it to:
modbase = ALIGN_UP(grub_end + 0x8000, GRUB_MOD_ALIGN);
both alignment and 0x8000 gap are still garanteed, without claiming more
space than necessary.
That is, if it really is a gap that you need :-)
> I haven't looked at binutils yet. Anyway, the problem doesn't exist
> with the current grub code because it suppressed build ID on
> kernel.elf. My workaround to get older grub compiled didn't actually
> strip build ID, it just fooled the objcopy test.
Ah, ok.
> But it would be great to detect and skip the segment corresponding to
> the build ID in grub-mkimage, just to make it more robust.
Can we make this work per inclusion rather than exclusion? The names
of needed segments are well-known, right?
> >>I actually doubt that it's the right behavior to go through segments.
> >
> >No idea about that I'm afraid :-(
>
> We need to figure out why the extra gap is needed. Maybe something
> doesn't get counted.
Yep. How did you find that an extra gap solves the problem?
> >>But maybe it's because in the normal mode with all modules loaded,
> >>unlike bare kernel.elf.
> >
> >But you don't need modules for ofdisk to work, it's built into the kernel.
>
> Just going to the rescue mode with the "rescue" command won't cause
> those hidden failures. It seems like they are caused by some missing
> module. I need to look into it.
It might be simpler than this. If you check what is the code flow between
those two:
disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00.
kern/disk.c:299: Opening `ide1/disk' failed.
that'll give more details.
--
Robert Millan
I know my rights; I want my phone call!
What use is a phone call, if you are unable to speak?
(as seen on /.)
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
Quoting Robert Millan <[EMAIL PROTECTED]>:
The module base address is calculated separately in kernel.elf and in
grub-mkimage. kernel.elf uses the "_end" symbol, whereas grub-mkimage
looks for the ELF segment with the highest end address.
Ok, so you mean this setting:
phdr->p_vaddr = grub_host_to_target32 (modbase);
phdr->p_paddr = grub_host_to_target32 (modbase);
is not what it's used to calculate _end ?
OK, it turns out the values of _end actually match, so it's not a problem.
It turns out there needs to be a gap between _end and the module base.
16k (0x4000) is not enough. 32k (0x8000) is enough.
This patch against the current CVS version fixes loading:
diff --git a/kern/powerpc/ieee1275/init.c b/kern/powerpc/ieee1275/init.c
index 4727d7d..d2fa980 100644
--- a/kern/powerpc/ieee1275/init.c
+++ b/kern/powerpc/ieee1275/init.c
@@ -231,5 +231,5 @@ grub_get_rtc (void)
grub_addr_t
grub_arch_modules_addr (void)
{
- return ALIGN_UP(_end, GRUB_MOD_ALIGN);
+ return ALIGN_UP(_end + 0x8000, GRUB_MOD_ALIGN);
}
diff --git a/util/elf/grub-mkimage.c b/util/elf/grub-mkimage.c
index 9e44af1..c39717a 100644
--- a/util/elf/grub-mkimage.c
+++ b/util/elf/grub-mkimage.c
@@ -228,6 +228,7 @@ add_segments (char *dir, FILE *out, int chrp, char
*mods[])
phdr->p_offset = grub_host_to_target32 (ALIGN_UP
(grub_util_get_fp_size (out),
sizeof (long)));
+ modbase += 0x8000;
load_modules (modbase, phdr, dir, mods, out);
}
One problem in grub-mkimage is the infamous build ID, which is present
in kernel.elf. It is located in a loadable segment starting at
0x1d4 (i.e. just about 256M). That's what confuses objcopy, and
it must be confusing grub-mkimage as well.
Isn't build ID a recent change in binutils? We had this problem for a while.
I haven't looked at binutils yet. Anyway, the problem doesn't exist
with the current grub code because it suppressed build ID on
kernel.elf. My workaround to get older grub compiled didn't actually
strip build ID, it just fooled the objcopy test.
But it would be great to detect and skip the segment corresponding to
the build ID in grub-mkimage, just to make it more robust.
I actually doubt that it's the right behavior to go through segments.
No idea about that I'm afraid :-(
We need to figure out why the extra gap is needed. Maybe something
doesn't get counted.
Linux style description. The first line is the synopsis. If it
doesn't fit 72 characters, the patch is a candidate for splitting.
Then an empty line. Then a more detailed description of the patch,
including the motivation behind the changes. The list of the affected
files can be generated by the version control system.
Looks good. But I guess you'll have to convince Marco and Okuji
about this :-)
Sure, it's in my TODO list :)
But maybe it's because in the normal mode with all modules loaded,
unlike bare kernel.elf.
But you don't need modules for ofdisk to work, it's built into the kernel.
Just going to the rescue mode with the "rescue" command won't cause
those hidden failures. It seems like they are caused by some missing
module. I need to look into it.
--
Regards,
Pavel Roskin
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Thu, Jan 03, 2008 at 03:09:17AM -0500, Pavel Roskin wrote: > Quoting Robert Millan <[EMAIL PROTECTED]>: > > >just take the grub-mkimage.c part of it and try to revert it on CVS HEAD, > >that would confirm it's a grub-mkimage problem. Then apply the hunks > >selectively untill you find the exact change that broke it. And finally > >it's just a matter of "looking hard" at that hunk untill it's coerced to > >reveal the problem :-) > > OK, here's what I have so far. The patch tries to make the memory > layout more compact. Two changes are make to the layout. kernel.elf > is loaded at 64k instead of 2M and the modules are loaded at the > lowest 4k boundary after kernel.elf rather that at 3M. > > Moving the kernel.elf load address is fine. Moving the modules is not. > > The module base address is calculated separately in kernel.elf and in > grub-mkimage. kernel.elf uses the "_end" symbol, whereas grub-mkimage > looks for the ELF segment with the highest end address. Ok, so you mean this setting: phdr->p_vaddr = grub_host_to_target32 (modbase); phdr->p_paddr = grub_host_to_target32 (modbase); is not what it's used to calculate _end ? I thought _end was calculated by the ELF loader (our own ELF loader, multiboot.c seems to calculate _end and pass it to its payload). > One problem in grub-mkimage is the infamous build ID, which is present > in kernel.elf. It is located in a loadable segment starting at > 0x1d4 (i.e. just about 256M). That's what confuses objcopy, and > it must be confusing grub-mkimage as well. Isn't build ID a recent change in binutils? We had this problem for a while. > I actually doubt that it's the right behavior to go through segments. No idea about that I'm afraid :-( > Linux style description. The first line is the synopsis. If it > doesn't fit 72 characters, the patch is a candidate for splitting. > Then an empty line. Then a more detailed description of the patch, > including the motivation behind the changes. The list of the affected > files can be generated by the version control system. Looks good. But I guess you'll have to convince Marco and Okuji about this :-) > The linear ChangeLog with everybody changing it in the same place (in > the beginning) doesn't work well with parallel development. It's not that much of a problem, I just write them in the patch header and copy them at the last minute before commit. > >>disk/ieee1275/ofdisk.c:65: Opening `ide1/disk:0'. > >>disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00. > >>kern/disk.c:299: Opening `ide1/disk' failed. > >>kern/disk.c:312: Closing `ide1/disk'. > > > >This seems to be contradictory. If OF returned a handle, why does the > >open fail ? Looks like GRUB doesn't like something but isn't telling you > >what. I'd investigate that part; at the least it can mean our error > >handling isn't good enough. > > Actually, there are no "failures" with the version from 2007-02-20. Does a snapshot from 2007-02-21 also have this problem? > But maybe it's because in the normal mode with all modules loaded, > unlike bare kernel.elf. But you don't need modules for ofdisk to work, it's built into the kernel. -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
Quoting Robert Millan <[EMAIL PROTECTED]>: just take the grub-mkimage.c part of it and try to revert it on CVS HEAD, that would confirm it's a grub-mkimage problem. Then apply the hunks selectively untill you find the exact change that broke it. And finally it's just a matter of "looking hard" at that hunk untill it's coerced to reveal the problem :-) OK, here's what I have so far. The patch tries to make the memory layout more compact. Two changes are make to the layout. kernel.elf is loaded at 64k instead of 2M and the modules are loaded at the lowest 4k boundary after kernel.elf rather that at 3M. Moving the kernel.elf load address is fine. Moving the modules is not. The module base address is calculated separately in kernel.elf and in grub-mkimage. kernel.elf uses the "_end" symbol, whereas grub-mkimage looks for the ELF segment with the highest end address. One problem in grub-mkimage is the infamous build ID, which is present in kernel.elf. It is located in a loadable segment starting at 0x1d4 (i.e. just about 256M). That's what confuses objcopy, and it must be confusing grub-mkimage as well. I actually doubt that it's the right behavior to go through segments. The "_end" marker should be located in a specific segment. And if the search through segments is correct, then maybe grub-mkimage should hardcore the module base into the output, rather than rely on kernel.elf doing the same calculation and getting the same result. All I need to to do fix the problem is to make kernel.elf and grub-mkimage come to the same value of the module base address. (Not to put any pressure of anyone, but GNU ChangeLog shows its age here - the detailed changes are described, but the motivation behind the whole patch is not, yet the details can be recovered with the version control, whereas the motivation has to be guessed) Full ack. But, you didn't mention any alternative. Linux style description. The first line is the synopsis. If it doesn't fit 72 characters, the patch is a candidate for splitting. Then an empty line. Then a more detailed description of the patch, including the motivation behind the changes. The list of the affected files can be generated by the version control system. The linear ChangeLog with everybody changing it in the same place (in the beginning) doesn't work well with parallel development. Both ide0/disk and cd refer to the CD-ROM. The messages are not shown if there is a CD in the drive. >What happens if you set debug=disk ? Typing from another monitor, sorry for possible typos. disk/ieee1275/ofdisk.c:65: Opening `ide1/disk:0'. disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00. kern/disk.c:299: Opening `ide1/disk' failed. kern/disk.c:312: Closing `ide1/disk'. This seems to be contradictory. If OF returned a handle, why does the open fail ? Looks like GRUB doesn't like something but isn't telling you what. I'd investigate that part; at the least it can mean our error handling isn't good enough. Actually, there are no "failures" with the version from 2007-02-20. But maybe it's because in the normal mode with all modules loaded, unlike bare kernel.elf. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Wed, Jan 02, 2008 at 01:46:04AM -0500, Pavel Roskin wrote: > Quoting Robert Millan <[EMAIL PROTECTED]>: > > >>My guess is kernel.elf doesn't include the necessary code. It's about > >>60k long. > > Now I'm sure about that. Unfortunately, grub-mkimage produces images > that the OpenFirmware fails to load with "CLAIM failed" (even with > just one short module). Indeed, bad things started with the first > commit on 2007-02-21. I'm afraid I won't be able to figure it out > without Hollis. It can mostly be solved by analizing/testing the regression diff. In August I sent an updated version that might be helpful: http://lists.gnu.org/archive/html/grub-devel/2007-08/msg00031.html just take the grub-mkimage.c part of it and try to revert it on CVS HEAD, that would confirm it's a grub-mkimage problem. Then apply the hunks selectively untill you find the exact change that broke it. And finally it's just a matter of "looking hard" at that hunk untill it's coerced to reveal the problem :-) This seems to affect many powermac users. I'd have gone through the bug myself, but I don't have access to the hardware. > (Not to put any pressure of anyone, but GNU ChangeLog shows its age > here - the detailed changes are described, but the motivation behind > the whole patch is not, yet the details can be recovered with the > version control, whereas the motivation has to be guessed) Full ack. But, you didn't mention any alternative. > Both ide0/disk and cd refer to the CD-ROM. The messages are not shown > if there is a CD in the drive. > > >What happens if you set debug=disk ? > > Typing from another monitor, sorry for possible typos. > > disk/ieee1275/ofdisk.c:65: Opening `ide1/disk:0'. > disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00. > kern/disk.c:299: Opening `ide1/disk' failed. > kern/disk.c:312: Closing `ide1/disk'. This seems to be contradictory. If OF returned a handle, why does the open fail ? Looks like GRUB doesn't like something but isn't telling you what. I'd investigate that part; at the least it can mean our error handling isn't good enough. -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
Quoting Robert Millan <[EMAIL PROTECTED]>: My guess is kernel.elf doesn't include the necessary code. It's about 60k long. Now I'm sure about that. Unfortunately, grub-mkimage produces images that the OpenFirmware fails to load with "CLAIM failed" (even with just one short module). Indeed, bad things started with the first commit on 2007-02-21. I'm afraid I won't be able to figure it out without Hollis. (Not to put any pressure of anyone, but GNU ChangeLog shows its age here - the detailed changes are described, but the motivation behind the whole patch is not, yet the details can be recovered with the version control, whereas the motivation has to be guessed) Sounds like "DISK-LABEL: read of block0 failed" is printed by the firmware and not by GRUB. Also, device enumeration is the same for all devices, so the fact that it only appears for some of them hints at a firmware bug. Both ide0/disk and cd refer to the CD-ROM. The messages are not shown if there is a CD in the drive. What happens if you set debug=disk ? Typing from another monitor, sorry for possible typos. grub rescue> ls (ide0/disk) kern/disk.c:220: Opening `ide0/disk'... disk/ieee1275/ofdisk.c:65: Opening `ide0/disk:0'. DISK-LABEL: read of block0 failed. kern/disk.c:299: Opening `ide0/disk' failed. kern/disk.c:312: Closing `ide0/disk'. (cd) kern/disk.c:220: Opening `cd'... disk/ieee1275/ofdisk.c:65: Opening `cd:0'. DISK-LABEL: read of block0 failed. kern/disk.c:299: Opening `cd' failed. kern/disk.c:312: Closing `cd'. (zip) kern/disk.c:220: Opening `zip'... disk/ieee1275/ofdisk.c:65: Opening `zip:0'. kern/disk.c:299: Opening `zip' failed. kern/disk.c:312: Closing `zip'. (disk/ide1) kern/disk.c:220: Opening `ide1/disk'... disk/ieee1275/ofdisk.c:65: Opening `ide1/disk:0'. disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00. kern/disk.c:299: Opening `ide1/disk' failed. kern/disk.c:312: Closing `ide1/disk'. (hd) kern/disk.c:220: Opening `hd'... disk/ieee1275/ofdisk.c:65: Opening `hd:0'. disk/ieee1275/ofdisk.c:74: Opened `hd:0' as handle 0xff9d1c00. kern/disk.c:299: Opening `hd' failed. kern/disk.c:312: Closing `hd'. (ultra0) kern/disk.c:220: Opening `ultra0'... disk/ieee1275/ofdisk.c:65: Opening `ultra0:0'. disk/ieee1275/ofdisk.c:74: Opened `ultra0:0' as handle 0xff9d1c00. kern/disk.c:299: Opening `ultra0' failed. kern/disk.c:312: Closing `ultra0'. error: unknown device grub rescue> -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Mon, Dec 31, 2007 at 05:37:35PM -0500, Pavel Roskin wrote: > > On Mon, 2007-12-31 at 09:45 +0100, Jan Nieuwenhuizen wrote: > > Pavel Roskin writes: > > > > > However, GRUB starts in the rescue mode, > > > and I cannot do anything in that mode. > > > > In rescue mode, type > > > > insmod normal > > normal > > > > That will print the error why the menu is not started, because > > this should have been automatic, or else it will starts the menu. > > Oh well, that PowerMac G4 won't work at all anymore (looks like a > hardware failure, there is no video output), so I'm trying it on > PowerMAC G3 (Blue&White). > > I copied grub.cfg and kernel.elf to the root of the HFS boot partition > hd:2. I entered openfirmware on startup by holding Alt-Mac-O-F. I used > "dir hd:2,\" to check that kernel.elf is there. Then I loaded it with > "boot hd:2,\kernel.elf". That's what I got: > > grub rescue> insmod normal > error: unknown device > grub rescue> normal > unknown command `normal' > Try `help' for usage > grub rescue> lsmod > NameRef Count Dependencies > grub rescue> set > prefix=(ultra0,2) > root=ultra0,2 > grub rescue> ls > (ide0/disk) DISK-LABEL: read of block0 failed > (cd) DISK-LABEL: read of block0 failed > (zip) (ide1/disk) (hd) (utltra0) > > My guess is kernel.elf doesn't include the necessary code. It's about > 60k long. Sounds like "DISK-LABEL: read of block0 failed" is printed by the firmware and not by GRUB. Also, device enumeration is the same for all devices, so the fact that it only appears for some of them hints at a firmware bug. What happens if you set debug=disk ? -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Mon, 2007-12-31 at 15:04 +0100, Robert Millan wrote: > On Mon, Dec 31, 2007 at 03:12:29AM -0500, Pavel Roskin wrote: > > Hello! > > > > I have tried the current GRUB on a PowerMac G4 running Fedora 8. > > > > If I follow the instructions at > > http://grub.enbug.org/TestingOnPowerPC, I cannot load grubof.modules. > > If I do it directly from openfirmware, I get "CLAIM failed" message. > > Known problem. I fixed this for Efika, but for some reason my fix didn't work > for PowerMac. Anyway, first of all I'd verify that if you revert to CVS > version before this commit: > > 2007-02-21 Hollis Blanchard <[EMAIL PROTECTED]> > > (both of them, actually) > > it works again. Yes, it's working. If doesn't load grub.cfg by default, but if I load it with "configfile", I can boot Linux from the menu! Sorry, I had to switch to a G3 machine in the meantime, and I didn't have a chance to test the current code on G3 system yet. "CLAIM failed" was on G4. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Mon, 2007-12-31 at 09:45 +0100, Jan Nieuwenhuizen wrote: > Pavel Roskin writes: > > > However, GRUB starts in the rescue mode, > > and I cannot do anything in that mode. > > In rescue mode, type > > insmod normal > normal > > That will print the error why the menu is not started, because > this should have been automatic, or else it will starts the menu. Oh well, that PowerMac G4 won't work at all anymore (looks like a hardware failure, there is no video output), so I'm trying it on PowerMAC G3 (Blue&White). I copied grub.cfg and kernel.elf to the root of the HFS boot partition hd:2. I entered openfirmware on startup by holding Alt-Mac-O-F. I used "dir hd:2,\" to check that kernel.elf is there. Then I loaded it with "boot hd:2,\kernel.elf". That's what I got: grub rescue> insmod normal error: unknown device grub rescue> normal unknown command `normal' Try `help' for usage grub rescue> lsmod NameRef Count Dependencies grub rescue> set prefix=(ultra0,2) root=ultra0,2 grub rescue> ls (ide0/disk) DISK-LABEL: read of block0 failed (cd) DISK-LABEL: read of block0 failed (zip) (ide1/disk) (hd) (utltra0) My guess is kernel.elf doesn't include the necessary code. It's about 60k long. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
On Mon, Dec 31, 2007 at 03:12:29AM -0500, Pavel Roskin wrote: > Hello! > > I have tried the current GRUB on a PowerMac G4 running Fedora 8. > > If I follow the instructions at > http://grub.enbug.org/TestingOnPowerPC, I cannot load grubof.modules. > If I do it directly from openfirmware, I get "CLAIM failed" message. Known problem. I fixed this for Efika, but for some reason my fix didn't work for PowerMac. Anyway, first of all I'd verify that if you revert to CVS version before this commit: 2007-02-21 Hollis Blanchard <[EMAIL PROTECTED]> (both of them, actually) it works again. I believe the kern/powerpc/ieee1275/init.c part of things doesn't need to be touched again after: 2007-10-07 Robert Millan <[EMAIL PROTECTED]> and that the problem affecting PowerMac was introduces with the rest of Hollis commit (that would be grub-mkimage.c ?). -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Testing on PowerMac G4
Pavel Roskin writes: > However, GRUB starts in the rescue mode, > and I cannot do anything in that mode. In rescue mode, type insmod normal normal That will print the error why the menu is not started, because this should have been automatic, or else it will starts the menu. Greetings, Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Testing on PowerMac G4
Hello! I have tried the current GRUB on a PowerMac G4 running Fedora 8. If I follow the instructions at http://grub.enbug.org/TestingOnPowerPC, I cannot load grubof.modules. If I do it directly from openfirmware, I get "CLAIM failed" message. I tried adding grubof.modules to the OS selection menu in ofboot.b script installed by yaboot, so that grubof.modules is loaded like yaboot. That doesn't work either. In some cases, I would get the openfirmware prompt, in other cases, the menu would restart. It looks like the attempt to load grubof.modules makes openfirmware unstable. I also tried loading kernel.elf created by the build process. It loads and shows the prompt. However, GRUB starts in the rescue mode, and I cannot do anything in that mode. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
