powerpc/sparc problems

powerpc/sparc problems

[Felix Zielcke]

David are you still there?
And also anyone who has access to a powerpc machine (and experience)?

In Debian we the problem that the `__ashldi3' and `__bswapsi2' symbols
can't be found in the grub-ieee1275 build on powerpc and also sparc.

Jordi already noticed this with the 1.96+20090721-4 IIRC and now other
people noticed this with 1.97~beta3
AFAICS there wasn't anything relevant changed on our side, so seems to
be a gcc issue.

`__ashldi3' is listed in include/grub/powerpc/libgcc.h and `__bswapsi2'
in the sparc64 header.
But something has now changed that this isn't enough anymore, at least
in Debian.

We used gcc 4.3.3 at the time Jordi noticed this and now switched to
gcc-4.4.1.

And David we still have this sparc bug open, which I forwared to
grub-devel:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538030


-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Re: powerpc/sparc problems

[David Miller]

From: Felix Zielcke <fzielcke@z-51.de>
Date: Mon, 12 Oct 2009 10:55:46 +0200

> And David we still have this sparc bug open, which I forwared to
> grub-devel:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538030

I'm about to head to Tokyo for the Linux Kernel summit and
the Japan Linux Symposium so I'll be out of commission for
a few weeks again.

Right when I'm about to get back to even trying out the latest
GRUB I hit another conference or major trip.

So please do not make me the critical link in the chain for Sparc
things until later this year.  If these things are to be fixed sooner
than that, someone else will need to look into them.

Re: powerpc/sparc problems

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]

Felix Zielcke wrote:
> David are you still there?
> And also anyone who has access to a powerpc machine (and experience)?
>
> In Debian we the problem that the `__ashldi3' and `__bswapsi2' symbols
> can't be found in the grub-ieee1275 build on powerpc and also sparc.
>
>   
I've come across the same problem when porting grub2 to MIPS. The
solution is the attached patch. I'll test it today on my imac g3
> Jordi already noticed this with the 1.96+20090721-4 IIRC and now other
> people noticed this with 1.97~beta3
> AFAICS there wasn't anything relevant changed on our side, so seems to
> be a gcc issue.
>
> `__ashldi3' is listed in include/grub/powerpc/libgcc.h and `__bswapsi2'
> in the sparc64 header.
> But something has now changed that this isn't enough anymore, at least
> in Debian.
>
> We used gcc 4.3.3 at the time Jordi noticed this and now switched to
> gcc-4.4.1.
>
> And David we still have this sparc bug open, which I forwared to
> grub-devel:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538030
>
>
>   


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 


[-- Attachment #2: ppcfix.diff --]
[-- Type: text/x-patch, Size: 1425 bytes --]

diff --git a/include/grub/powerpc/libgcc.h b/include/grub/powerpc/libgcc.h
index ea4b073..0ff8964 100644
--- a/include/grub/powerpc/libgcc.h
+++ b/include/grub/powerpc/libgcc.h
@@ -16,9 +16,9 @@
  *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
  */
 
-void EXPORT_FUNC (memset) (void) __attribute__ ((weak));
-void EXPORT_FUNC (__ashldi3) (void) __attribute__ ((weak));
-void EXPORT_FUNC (__ashrdi3) (void) __attribute__ ((weak));
-void EXPORT_FUNC (__lshrdi3) (void) __attribute__ ((weak));
-void EXPORT_FUNC (__trampoline_setup) (void) __attribute__ ((weak));
-void EXPORT_FUNC (__ucmpdi2) (void) __attribute__ ((weak));
+void EXPORT_FUNC (memset) (void);
+void EXPORT_FUNC (__ashldi3) (void);
+void EXPORT_FUNC (__ashrdi3) (void);
+void EXPORT_FUNC (__lshrdi3) (void);
+void EXPORT_FUNC (__trampoline_setup) (void);
+void EXPORT_FUNC (__ucmpdi2) (void);
diff --git a/include/grub/sparc64/libgcc.h b/include/grub/sparc64/libgcc.h
index 5d18c5c..6a3d804 100644
--- a/include/grub/sparc64/libgcc.h
+++ b/include/grub/sparc64/libgcc.h
@@ -21,7 +21,7 @@
 void EXPORT_FUNC (memset) (void);
 
 typedef int SItype __attribute__ ((mode (SI)));
-SItype EXPORT_FUNC (__bswapsi2) (SItype) __attribute__ ((weak));
+SItype EXPORT_FUNC (__bswapsi2) (SItype);
 
 typedef int DItype __attribute__ ((mode (DI)));
-DItype EXPORT_FUNC (__bswapdi2) (DItype) __attribute__ ((weak));
+DItype EXPORT_FUNC (__bswapdi2) (DItype);

Re: powerpc/sparc problems

[Felix Zielcke]

Am Montag, den 12.10.2009, 10:55 +0200 schrieb Felix Zielcke:

> And also anyone who has access to a powerpc machine (and experience)?

Oh and I forgot to mention, that the powerpc version doestn't even build
now with 1.97~beta4:

_restgpr_31_x in boot is not defined

Full build log is here:
https://buildd.debian.org/fetch.cgi?&pkg=grub2&ver=1.97~beta4-1&arch=powerpc&stamp=1254771207&file=log


-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Re: powerpc/sparc problems

[Felix Zielcke]

Am Montag, den 12.10.2009, 02:05 -0700 schrieb David Miller:
> From: Felix Zielcke <fzielcke@z-51.de>
> Date: Mon, 12 Oct 2009 10:55:46 +0200
> 
> > And David we still have this sparc bug open, which I forwared to
> > grub-devel:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538030
> 
> I'm about to head to Tokyo for the Linux Kernel summit and
> the Japan Linux Symposium so I'll be out of commission for
> a few weeks again.
> 
> Right when I'm about to get back to even trying out the latest
> GRUB I hit another conference or major trip.
> 
> So please do not make me the critical link in the chain for Sparc
> things until later this year.  If these things are to be fixed sooner
> than that, someone else will need to look into them.

Thanks for looking into this, even if it's not now :)
Unfortunately AFAIR you're the only sparc guy on the list here or am I
wrong?

For me this isn't that important. For the 1.97 release I wouldn't anyway
declare sparc as a fully stable port.
And in Debian powerpc and sparc isn't that much used.


-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Re: powerpc/sparc problems

[Vladimir 'phcoder' Serbinenko]

David Miller wrote:
> From: Felix Zielcke <fzielcke@z-51.de>
> Date: Mon, 12 Oct 2009 10:55:46 +0200
>
>   
>> And David we still have this sparc bug open, which I forwared to
>> grub-devel:
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538030
>>     
>
> I'm about to head to Tokyo for the Linux Kernel summit and
> the Japan Linux Symposium so I'll be out of commission for
> a few weeks again.
>
> Right when I'm about to get back to even trying out the latest
> GRUB I hit another conference or major trip.
>
> So please do not make me the critical link in the chain for Sparc
> things until later this year.  If these things are to be fixed sooner
> than that, someone else will need to look into them.
>
>   
How accurate is qemu-system-sparc64? We could have an automated
regression testing for it - this should keep grub-sparc reasonably
working and permit minor (and perhaps even major) developpement
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 

Re: powerpc/sparc problems

[Bean]

On Mon, Oct 12, 2009 at 4:55 PM, Felix Zielcke <fzielcke@z-51.de> wrote:
> David are you still there?
> And also anyone who has access to a powerpc machine (and experience)?
>
> In Debian we the problem that the `__ashldi3' and `__bswapsi2' symbols
> can't be found in the grub-ieee1275 build on powerpc and also sparc.
>
> Jordi already noticed this with the 1.96+20090721-4 IIRC and now other
> people noticed this with 1.97~beta3
> AFAICS there wasn't anything relevant changed on our side, so seems to
> be a gcc issue.
>
> `__ashldi3' is listed in include/grub/powerpc/libgcc.h and `__bswapsi2'
> in the sparc64 header.
> But something has now changed that this isn't enough anymore, at least
> in Debian.
>
> We used gcc 4.3.3 at the time Jordi noticed this and now switched to
> gcc-4.4.1.
>
> And David we still have this sparc bug open, which I forwared to
> grub-devel:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538030

Hi,

Try my branch, it includes the libgcc functions in grub instead of
rely on external library. It builds and run properly for
powerpc-ieee1275 last time I check.

-- 
Bean

gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/

Re: powerpc/sparc problems

[David Miller]

From: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>
Date: Mon, 12 Oct 2009 11:56:23 +0200

> How accurate is qemu-system-sparc64? We could have an automated
> regression testing for it - this should keep grub-sparc reasonably
> working and permit minor (and perhaps even major) developpement

Personally, I don't know as I've never used it.

Re: powerpc/sparc problems

[David Miller]

From: Bean <bean123ch@gmail.com>
Date: Mon, 12 Oct 2009 17:58:42 +0800

> Try my branch, it includes the libgcc functions in grub instead of
> rely on external library. It builds and run properly for
> powerpc-ieee1275 last time I check.

Good luck when the compiler changes the interface and/or semantics of
these routines in a future version.  Will you enumerate your in-tree
copies by gcc version with ifdefs or similar?

That's why gcc and it's libgcc are distributed together, and gcc
configures itself to link with a specific libgcc and only that libgcc.

This whole things perfectly fine in GRUB when I implemented the
necessary machinery to find if these routines exist in libgcc at
configure time and to reference them properly in the build.

They've merely been broken meanwhile and someone just needs to rectify
that regression.

Re: powerpc/sparc problems

[Vladimir 'phcoder' Serbinenko]

David Miller wrote:
> From: Bean <bean123ch@gmail.com>
> Date: Mon, 12 Oct 2009 17:58:42 +0800
>
>   
>> Try my branch, it includes the libgcc functions in grub instead of
>> rely on external library. It builds and run properly for
>> powerpc-ieee1275 last time I check.
>>     
>
> Good luck when the compiler changes the interface and/or semantics of
> these routines in a future version.  Will you enumerate your in-tree
> copies by gcc version with ifdefs or similar?
>
> That's why gcc and it's libgcc are distributed together, and gcc
> configures itself to link with a specific libgcc and only that libgcc.
>
> This whole things perfectly fine in GRUB when I implemented the
> necessary machinery to find if these routines exist in libgcc at
> configure time and to reference them properly in the build.
>
> They've merely been broken meanwhile and someone just needs to rectify
> that regression.
>
>
>   
It was removed as a part of following commit
2009-06-10  Pavel Roskin  <proski@gnu.org>

        * configure.ac: Use -nostdlib when probing for the target.  It
        should not be required to have libc for the target.

        * configure.ac: Remove checks for __bswapsi2 and __bswapdi2,
        they fail without libc headers for the target.
        * include/grub/powerpc/libgcc.h: Use weak attribute for all
        exports.
        * include/grub/sparc64/libgcc.h: Likewise.  Don't use
        preprocessor conditionals.

Do you think we should just revert it?
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 

Re: powerpc/sparc problems

[Felix Zielcke]

Am Montag, den 12.10.2009, 11:56 +0200 schrieb Vladimir 'phcoder'
Serbinenko:
> How accurate is qemu-system-sparc64?

The qemu status page says `Dev only' in red.
Both Debian lenny and testing sparc isos don't boot. It hangs at
`Welcome to OpenBIOS'
With qemu-system-sparc the cd boots but then complains that only 64bit
sparc systems are now supported.

The OpenSolaris sparc CD directly goes to an OpenFirmware prompt with
-sparc64
With -sparc it prints some stuff and then `Unsupported image format'

-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Re: powerpc/sparc problems

[David Miller]

From: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>
Date: Mon, 12 Oct 2009 12:26:04 +0200

> It was removed as a part of following commit
> 2009-06-10  Pavel Roskin  <proski@gnu.org>
> 
>         * configure.ac: Use -nostdlib when probing for the target.  It
>         should not be required to have libc for the target.
> 
>         * configure.ac: Remove checks for __bswapsi2 and __bswapdi2,
>         they fail without libc headers for the target.
>         * include/grub/powerpc/libgcc.h: Use weak attribute for all
>         exports.
>         * include/grub/sparc64/libgcc.h: Likewise.  Don't use
>         preprocessor conditionals.
> 
> Do you think we should just revert it?

Probably.

Re: powerpc/sparc problems

[Bean]

On Mon, Oct 12, 2009 at 6:14 PM, David Miller <davem@davemloft.net> wrote:
> From: Bean <bean123ch@gmail.com>
> Date: Mon, 12 Oct 2009 17:58:42 +0800
>
>> Try my branch, it includes the libgcc functions in grub instead of
>> rely on external library. It builds and run properly for
>> powerpc-ieee1275 last time I check.
>
> Good luck when the compiler changes the interface and/or semantics of
> these routines in a future version.  Will you enumerate your in-tree
> copies by gcc version with ifdefs or similar?
>
> That's why gcc and it's libgcc are distributed together, and gcc
> configures itself to link with a specific libgcc and only that libgcc.
>
> This whole things perfectly fine in GRUB when I implemented the
> necessary machinery to find if these routines exist in libgcc at
> configure time and to reference them properly in the build.
>
> They've merely been broken meanwhile and someone just needs to rectify
> that regression.
>

Hi,

To use the libgcc, we need to link the object file, this doesn't work
in system that use non ELF format like mach-o. And actually, the int
function rarely changed, and some project like openbios also include
the libgcc function directly.

-- 
Bean

gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/

Re: powerpc/sparc problems

[David Miller]

From: Bean <bean123ch@gmail.com>
Date: Mon, 12 Oct 2009 18:31:12 +0800

> To use the libgcc, we need to link the object file, this doesn't work
> in system that use non ELF format like mach-o.

How can one even build programs in the mach-o format if linking
object files is not allowed? :-)

If this is just for embedded cross compile situations, just forget it.

We just require that you have a fully functioning cross build
environment and that means you need to have a C library around.

Re: powerpc/sparc problems

[Bean]

On Mon, Oct 12, 2009 at 7:07 PM, David Miller <davem@davemloft.net> wrote:
> From: Bean <bean123ch@gmail.com>
> Date: Mon, 12 Oct 2009 18:31:12 +0800
>
>> To use the libgcc, we need to link the object file, this doesn't work
>> in system that use non ELF format like mach-o.
>
> How can one even build programs in the mach-o format if linking
> object files is not allowed? :-)
>
> If this is just for embedded cross compile situations, just forget it.
>
> We just require that you have a fully functioning cross build
> environment and that means you need to have a C library around.

Hi,

One of the main platform of powerpc-ieee1275 is apple's ppc machine,
which installs OSX by default. But OSX uses mach-o object and
executable file, not ELF. The mach-o image generated by gcc of OSX
isn't recognized by the ieee1275 firmware.

-- 
Bean

gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/

Re: powerpc/sparc problems

[Pavel Roskin]

On Mon, 2009-10-12 at 03:28 -0700, David Miller wrote:
> > Do you think we should just revert it?
> 
> Probably.

The purpose of the patch was to remove the requirement that the target
libc development package is present.  That's a common situation for
x86_64 systems that may have a 32-bit capable compiler, and maybe the
32-bit libc installed as a dependency of a 32-bit package (e.g. wine),
but no the files necessary to link against the 32-bit libc.

I don't know why the checks need to be reinstated, but if it's really
needed to be done, we could use the trick described in the gcc manual:

`-print-libgcc-file-name'
     Same as `-print-file-name=libgcc.a'.

     This is useful when you use `-nostdlib' or `-nodefaultlibs' but
     you do want to link with `libgcc.a'.  You can do

          gcc -nostdlib FILES... `gcc -print-libgcc-file-name`

This way, it should be possible to check if the functions are in libgcc
without requiring libc.

-- 
Regards,
Pavel Roskin

Re: powerpc/sparc problems

[Vladimir 'phcoder' Serbinenko]

Pavel Roskin wrote:
> On Mon, 2009-10-12 at 03:28 -0700, David Miller wrote:
>   
>>> Do you think we should just revert it?
>>>       
>> Probably.
>>     
>
> The purpose of the patch was to remove the requirement that the target
> libc development package is present.  That's a common situation for
> x86_64 systems that may have a 32-bit capable compiler, and maybe the
> 32-bit libc installed as a dependency of a 32-bit package (e.g. wine),
> but no the files necessary to link against the 32-bit libc.
>
> I don't know why the checks need to be reinstated, but if it's really
> needed to be done, we could use the trick described in the gcc manual:
>
> `-print-libgcc-file-name'
>      Same as `-print-file-name=libgcc.a'.
>
>      This is useful when you use `-nostdlib' or `-nodefaultlibs' but
>      you do want to link with `libgcc.a'.  You can do
>
>           gcc -nostdlib FILES... `gcc -print-libgcc-file-name`
>
> This way, it should be possible to check if the functions are in libgcc
> without requiring libc.
>   
On sparc64, ppc and mips we compile using -nostdlib -lgcc
-static-libgcc. I would prefer to use the same method in check and
actual compile.

Another idea: we could use nm to generate list of functions in libgcc.
This way we acquire robustness against new functions in gcc but it may
increase the kernel size. PPC and sparc are less used and hence more
prone to problems and size on them doesn't matter so much as it does on
i386-pc. So I would prefer to buy robustness at cost of size
I haven't made up my mind for mips(el) yet since the target is to be
burned in flash where space is limited.
Another solution would be to enumerate symbols in all modules and
compare them to libgcc symbols and include only needed ones but it has a
major drawback of potentially breaking external and separately compiled
modules which is especially problematic if core is burned in flash.

-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 

Re: powerpc/sparc problems

[Pavel Roskin]

On Mon, 2009-10-12 at 17:45 +0200, Vladimir 'phcoder' Serbinenko wrote:
> On sparc64, ppc and mips we compile using -nostdlib -lgcc
> -static-libgcc. I would prefer to use the same method in check and
> actual compile.

Ideally, we should use those flags on all architectures.

-- 
Regards,
Pavel Roskin

Re: powerpc/sparc problems

[David Miller]

From: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>
Date: Mon, 12 Oct 2009 17:45:33 +0200

> Another idea: we could use nm to generate list of functions in libgcc.

Yes, 'nm' would work too.

Re: powerpc/sparc problems

[Robert Millan]

On Mon, Oct 12, 2009 at 06:31:12PM +0800, Bean wrote:
> On Mon, Oct 12, 2009 at 6:14 PM, David Miller <davem@davemloft.net> wrote:
> >
> > Good luck when the compiler changes the interface and/or semantics of
> > these routines in a future version.  Will you enumerate your in-tree
> > copies by gcc version with ifdefs or similar?
> >
> > That's why gcc and it's libgcc are distributed together, and gcc
> > configures itself to link with a specific libgcc and only that libgcc.
> >
> > This whole things perfectly fine in GRUB when I implemented the
> > necessary machinery to find if these routines exist in libgcc at
> > configure time and to reference them properly in the build.
> >
> > They've merely been broken meanwhile and someone just needs to rectify
> > that regression.
> >
> 
> Hi,
> 
> To use the libgcc, we need to link the object file, this doesn't work
> in system that use non ELF format like mach-o. And actually, the int
> function rarely changed, and some project like openbios also include
> the libgcc function directly.

David is right.  We shouldn't embed a copy of libgcc code if we can avoid it.

If an OS uses mach-o, it just means when compiling native programs they need
to be in that format, but this is unrelated with the format used by GRUB.  GRUB
can be built on top of any OS, provided that its dependencies (including an
ELF-capable toolchain) were installed.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: powerpc/sparc problems

[Vladimir 'phcoder' Serbinenko]

David Miller wrote:
> From: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>
> Date: Mon, 12 Oct 2009 12:26:04 +0200
>
>   
>> It was removed as a part of following commit
>> 2009-06-10  Pavel Roskin  <proski@gnu.org>
>>
>>         * configure.ac: Use -nostdlib when probing for the target.  It
>>         should not be required to have libc for the target.
>>
>>         * configure.ac: Remove checks for __bswapsi2 and __bswapdi2,
>>         they fail without libc headers for the target.
>>         * include/grub/powerpc/libgcc.h: Use weak attribute for all
>>         exports.
>>         * include/grub/sparc64/libgcc.h: Likewise.  Don't use
>>         preprocessor conditionals.
>>
>> Do you think we should just revert it?
>>     
>
> Probably.
>
>   
The methods discussed in this thread are good but aren't for release. So
I just reverted Pavel's commit


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 

Re: powerpc/sparc problems

[Pavel Roskin]

On Thu, 2009-10-15 at 13:58 +0200, Vladimir 'phcoder' Serbinenko wrote:

> The methods discussed in this thread are good but aren't for release. So
> I just reverted Pavel's commit

My cross-build for sparc64 fails now:

__bswapsi2 in fat is not defined

This can be traced to the following part of config.log:

configure:7314: checking for __bswapsi2
configure:7370: sparc64-linux-uclibc-gcc -o conftest -Wall -W -Wshadow
-Wpointer-arith -Wmissing-prototypes                  -Wundef
-Wstrict-prototypes -g -Os -m64 -fno-stack-protector -Werror -nostdlib
-Wl,--defsym,___main=0x8100   -m64 conftest.c  >&5
In file included
from /opt/sparc/usr/lib/gcc/sparc64-linux-uclibc/4.3.3/include-fixed/syslimits.h:7,

from /opt/sparc/usr/lib/gcc/sparc64-linux-uclibc/4.3.3/include-fixed/limits.h:11,
                 from conftest.c:38:
/opt/sparc/usr/lib/gcc/sparc64-linux-uclibc/4.3.3/include-fixed/limits.h:122:61: error: no include path in which to search for limits.h
cc1: warnings being treated as errors
conftest.c:51: error: function declaration isn't a prototype
configure:7377: $? = 1

The reason limits.h is missing is because I failed to compile uClibc for
sparc64 using buildroot.

But even if I create an empty /opt/sparc/usr/include/limits.h, the test
fails:

configure:7314: checking for __bswapsi2
configure:7370: gcc -o conftest -Wall -W -Wshadow -Wpointer-arith
-Wmissing-prototypes                  -Wundef -Wstrict-prototypes -g -Os
-fno-dwarf2-cfi-asm -m64 -fno-stack-protector -mno-stack-arg-probe
-Werror -nostdlib -Wl,--defsym,___main=0x8100   -m64 conftest.c  >&5
cc1: warnings being treated as errors
conftest.c:51: error: function declaration isn't a prototype
configure:7377: $? = 1

I'm afraid it's a real bug that would affect native compilation.  We
should move adding -Werror to TARGET_CFLAGS after all checks.

Even after I do that, I still get:

configure:7305: checking for __bswapsi2
configure:7361: gcc -o conftest -Wall -W -Wshadow -Wpointer-arith
-Wmissing-prototypes                  -Wundef -Wstrict-prototypes -g -Os
-fno-dwarf2-cfi-asm -m64 -fno-stack-protector -mno-stack-arg-probe
-nostdlib -Wl,--defsym,___main=0x8100   -m64 conftest.c  >&5
conftest.c:51: warning: function declaration isn't a prototype
/usr/bin/ld: warning: cannot find entry symbol _start; defaulting to
0000000000400144
/tmp/ccoCvQMe.o: In function `main':
/home/proski/src/grub2.git/build-ieee1275-sparc64-linux-uclibc/conftest.c:62: undefined reference to `__bswapsi2'
collect2: ld returned 1 exit status
configure:7368: $? = 1

That may or may not be due to the lack of the libc.  I tried checking
for __ashldi3, which is exported unconditionally on PowerPC, and the
check fails, even though I have libc for PowerPC.  That's also a
cross-compiler, but I can test it on a PowerMac if necessary.

This makes me think that checks for __bswapsi2 and  __bswapdi2 will fail
on Sparc64, even if those functions are present and even if
--disable-werror is used.

-- 
Regards,
Pavel Roskin

Re: powerpc/sparc problems

[David Miller]

From: Pavel Roskin <proski@gnu.org>
Date: Thu, 15 Oct 2009 18:41:41 -0400

> This makes me think that checks for __bswapsi2 and  __bswapdi2 will fail
> on Sparc64, even if those functions are present and even if
> --disable-werror is used.

They worked perfectly fine for me on a real system with
a real compiler and glibc.

If you're going to use cross compilation to test, use
a full cross toolset and glibc build not some hacked
up uclibc thing.

I also believe that even if it still fails for you,
native building is more important to work than cross
building situations.

Re: powerpc/sparc problems

[Pavel Roskin]

Quoting David Miller <davem@davemloft.net>:

> From: Pavel Roskin <proski@gnu.org>
> Date: Thu, 15 Oct 2009 18:41:41 -0400
>
>> This makes me think that checks for __bswapsi2 and  __bswapdi2 will fail
>> on Sparc64, even if those functions are present and even if
>> --disable-werror is used.
>
> They worked perfectly fine for me on a real system with
> a real compiler and glibc.

I don't think we can rely on testing done months ago.  Now that we use  
-Werror by default, the checks would fail even natively.  It they  
don't, I'd like to see the relevant excerpt from your config.log.

I'm going to test the native PowerPC build later today.

-- 
Regards,
Pavel Roskin

Re: powerpc/sparc problems

[Pavel Roskin]

On Fri, 2009-10-16 at 05:44 -0700, David Miller wrote:
> From: Pavel Roskin <proski@gnu.org>
> Date: Thu, 15 Oct 2009 18:41:41 -0400
> 
> > This makes me think that checks for __bswapsi2 and  __bswapdi2 will fail
> > on Sparc64, even if those functions are present and even if
> > --disable-werror is used.
> 
> They worked perfectly fine for me on a real system with
> a real compiler and glibc.
> 
> If you're going to use cross compilation to test, use
> a full cross toolset and glibc build not some hacked
> up uclibc thing.

I have tested the current GRUB on PowerPC.  It's Fedora 11 with a real
glibc.  I added __ashldi3 to the arguments of AC_CHECK_FUNCS.  The check
fails.  Yet __ashldi3 is present in libgcc and is exported
unconditionally.

The reason is that -nostdlib is added to CFLAGS immediately above 
AC_CHECK_FUNCS.  -nostdlib disables linking against libgcc.

I believe the checks for __bswapsi2 __bswapdi2 would fail on sparc64 for
the same reason.

Also, I believe the effect of -Werror on the test will be seen on
sparc64.  Adding -Werror should be after all tests and there should be a
big warning in configure.ac telling not to add tests after that point.

> I also believe that even if it still fails for you,
> native building is more important to work than cross
> building situations.

It is a native build and the current code.

The whole reason I removed the checks is because they stopped working
correctly when the target libc requirement was eliminated.  Restoring
the checks without removing -nostdlib not going to help.

I'm surprised that my code is being reverted immediately before the
release and the result is not tested.  It's one thing to revert the code
that has just been committed, and it's entirely different when the code
has been in the repository for months.

-- 
Regards,
Pavel Roskin

Re: powerpc/sparc problems

[Vladimir 'phcoder' Serbinenko]

Pavel Roskin wrote:
> On Fri, 2009-10-16 at 05:44 -0700, David Miller wrote:
>   
>> From: Pavel Roskin <proski@gnu.org>
>> Date: Thu, 15 Oct 2009 18:41:41 -0400
>>
>>     
>>> This makes me think that checks for __bswapsi2 and  __bswapdi2 will fail
>>> on Sparc64, even if those functions are present and even if
>>> --disable-werror is used.
>>>       
>> They worked perfectly fine for me on a real system with
>> a real compiler and glibc.
>>
>> If you're going to use cross compilation to test, use
>> a full cross toolset and glibc build not some hacked
>> up uclibc thing.
>>     
>
> I have tested the current GRUB on PowerPC.  It's Fedora 11 with a real
> glibc.  I added __ashldi3 to the arguments of AC_CHECK_FUNCS.  The check
> fails.  Yet __ashldi3 is present in libgcc and is exported
> unconditionally.
>
> The reason is that -nostdlib is added to CFLAGS immediately above 
> AC_CHECK_FUNCS.  -nostdlib disables linking against libgcc.
>
> I believe the checks for __bswapsi2 __bswapdi2 would fail on sparc64 for
> the same reason.
>
> Also, I believe the effect of -Werror on the test will be seen on
> sparc64.  Adding -Werror should be after all tests and there should be a
> big warning in configure.ac telling not to add tests after that point.
>
>   
>> I also believe that even if it still fails for you,
>> native building is more important to work than cross
>> building situations.
>>     
>
> It is a native build and the current code.
>
> The whole reason I removed the checks is because they stopped working
> correctly when the target libc requirement was eliminated.  Restoring
> the checks without removing -nostdlib not going to help.
>
> I'm surprised that my code is being reverted immediately before the
> release and the result is not tested.  It's one thing to revert the code
> that has just been committed, and it's entirely different when the code
> has been in the repository for months.
>
>   
I've tested only the code as it was for powerpc. I'm sorry that I
haven't checked sparc64 part but I haven't yet installed sparc64
cross-compile (it's unavailable from emdebian and compiling it oneself
is painful)


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 

Re: powerpc/sparc problems

[Robert Millan]

On Fri, Oct 16, 2009 at 09:21:36PM -0400, Pavel Roskin wrote:
> On Fri, 2009-10-16 at 05:44 -0700, David Miller wrote:
> > 
> > They worked perfectly fine for me on a real system with
> > a real compiler and glibc.
> > 
> > If you're going to use cross compilation to test, use
> > a full cross toolset and glibc build not some hacked
> > up uclibc thing.

But we're testing a feature of libgcc, not glibc.

> I have tested the current GRUB on PowerPC.  It's Fedora 11 with a real
> glibc.  I added __ashldi3 to the arguments of AC_CHECK_FUNCS.  The check
> fails.  Yet __ashldi3 is present in libgcc and is exported
> unconditionally.
> 
> The reason is that -nostdlib is added to CFLAGS immediately above 
> AC_CHECK_FUNCS.  -nostdlib disables linking against libgcc.
> 
> I believe the checks for __bswapsi2 __bswapdi2 would fail on sparc64 for
> the same reason.

Then why not just add -lgcc after -nostdlib?

> I'm surprised that my code is being reverted immediately before the
> release and the result is not tested.

I was under the impression that there was consensus that it should be
reverted.  Excuse me for not having tracked this more closely.

Looking at 2631:2632, it seems to me that:

  - Using configure checks is the right way, we just need to make them
    work (I think -lgcc should do it).

  - The ifdef wraps that have been added to sparc64/libgcc.h should also be
    in powerpc/libgcc.h.

>  It's one thing to revert the code
> that has just been committed, and it's entirely different when the code
> has been in the repository for months.

Yes.  There's been a long freeze period during which it'd have been more
appropiate to discuss this kind of things...

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: powerpc/sparc problems

[rubisher]

Felix Zielcke wrote:
> Am Montag, den 12.10.2009, 10:55 +0200 schrieb Felix Zielcke:
> 
>> And also anyone who has access to a powerpc machine (and experience)?
> 
> Oh and I forgot to mention, that the powerpc version doestn't even build
> now with 1.97~beta4:
> 
> _restgpr_31_x in boot is not defined
> 
> Full build log is here:
> https://buildd.debian.org/fetch.cgi?&pkg=grub2&ver=1.97~beta4-1&arch=powerpc&stamp=1254771207&file=log
> 
> 
Hello Felix,

I now reach to install grub for my debian unstable installation on my ibm p5 lpar (the unstable 1.97~beta3-1) but 
unfortunately failed to boot because failed to find a symbol (sorry I forget to take note of it).
I so jump to svn (release 2641 and today 2642); no luck always this same error:

_restgpr_31_x in boot is not defined

I so re-try to build the deb pkg 1.97~beta3-1; too bad again this same error???

Could it be so a gcc issue (debian build of 1.97~beta3-1 was with gcc-4.4 4.4.1-3; here I rebuild with gcc-4.4 4.4.1-6 and 
even most recent 4.4.2-1?)

I so try to come back to gcc 4.3 and this time it build fine (not yet tested if this one boot, sorry).

Any idea?

Tia,
	j.

ps: I also tried to test bean123 git branch (grab this Oct 19) but this failed to build early to compile normal/main.c (gcc 
didn't find some references to some grub_... struct and fnct)

Re: powerpc/sparc problems

[Vladimir 'phcoder' Serbinenko]

rubisher wrote:
> Felix Zielcke wrote:
>> Am Montag, den 12.10.2009, 10:55 +0200 schrieb Felix Zielcke:
>>
>>> And also anyone who has access to a powerpc machine (and experience)?
>>
>> Oh and I forgot to mention, that the powerpc version doestn't even build
>> now with 1.97~beta4:
>>
>> _restgpr_31_x in boot is not defined
>>
>> Full build log is here:
>> https://buildd.debian.org/fetch.cgi?&pkg=grub2&ver=1.97~beta4-1&arch=powerpc&stamp=1254771207&file=log
>>
>>
>>
> Hello Felix,
>
> I now reach to install grub for my debian unstable installation on my
> ibm p5 lpar (the unstable 1.97~beta3-1) but unfortunately failed to
> boot because failed to find a symbol (sorry I forget to take note of it).
> I so jump to svn (release 2641 and today 2642); no luck always this
> same error:
>
> _restgpr_31_x in boot is not defined
From the name and what we discussed with Felix on IRC I guess this
symbol is a counterpart of MIPS' __gnu_local_gp which is used in
handling GOT relocations which allow usage of a single instruction to
load 32-bit address instead of usual 2 but require linker to generate
additional table. You can look into kern/mips/dl.c of my mips branch for
details. Similar approach can be used for powerpc. I suppose it would be
a good idea to put this code to kern/got.c instead of kern/<arch>. But
such a change just before release is too big.
Since it correspond to a recent change in gcc behaviour perhaps an old
behaviour can be restored with an option.
>
> I so re-try to build the deb pkg 1.97~beta3-1; too bad again this same
> error???
>
> Could it be so a gcc issue (debian build of 1.97~beta3-1 was with
> gcc-4.4 4.4.1-3; here I rebuild with gcc-4.4 4.4.1-6 and even most
> recent 4.4.2-1?)
>
> I so try to come back to gcc 4.3 and this time it build fine (not yet
> tested if this one boot, sorry).
>
> Any idea?
>
> Tia,
>     j.
>
> ps: I also tried to test bean123 git branch (grab this Oct 19) but
> this failed to build early to compile normal/main.c (gcc didn't find
> some references to some grub_... struct and fnct)
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 

Re: powerpc/sparc problems

[rubisher]

Hello Vladimir,

Vladimir 'phcoder' Serbinenko wrote:
> rubisher wrote:
>> Felix Zielcke wrote:
>>> Am Montag, den 12.10.2009, 10:55 +0200 schrieb Felix Zielcke:
>>>
>>>> And also anyone who has access to a powerpc machine (and experience)?
>>> Oh and I forgot to mention, that the powerpc version doestn't even build
>>> now with 1.97~beta4:
>>>
>>> _restgpr_31_x in boot is not defined
>>>
>>> Full build log is here:
>>> https://buildd.debian.org/fetch.cgi?&pkg=grub2&ver=1.97~beta4-1&arch=powerpc&stamp=1254771207&file=log
>>>
>>>
>>>
>> Hello Felix,
>>
>> I now reach to install grub for my debian unstable installation on my
>> ibm p5 lpar (the unstable 1.97~beta3-1) but unfortunately failed to
>> boot because failed to find a symbol (sorry I forget to take note of it).
>> I so jump to svn (release 2641 and today 2642); no luck always this
>> same error:
>>
>> _restgpr_31_x in boot is not defined
>>From the name and what we discussed with Felix on IRC I guess this
> symbol is a counterpart of MIPS' __gnu_local_gp which is used in
> handling GOT relocations which allow usage of a single instruction to
> load 32-bit address instead of usual 2 but require linker to generate
> additional table. You can look into kern/mips/dl.c of my mips branch for
> details. Similar approach can be used for powerpc. I suppose it would be
> a good idea to put this code to kern/got.c instead of kern/<arch>. But
> such a change just before release is too big.
> Since it correspond to a recent change in gcc behaviour perhaps an old
> behaviour can be restored with an option.

I well reach to grab your mips git tree, but I don't have deep knowledge in programming, so I will need a bit of time to 
analyse ;<)

Tx a lot,
	J.

>> I so re-try to build the deb pkg 1.97~beta3-1; too bad again this same
>> error???
>>
>> Could it be so a gcc issue (debian build of 1.97~beta3-1 was with
>> gcc-4.4 4.4.1-3; here I rebuild with gcc-4.4 4.4.1-6 and even most
>> recent 4.4.2-1?)
>>
>> I so try to come back to gcc 4.3 and this time it build fine (not yet
>> tested if this one boot, sorry).
>>
>> Any idea?
>>
>> Tia,
>>     j.
>>
>> ps: I also tried to test bean123 git branch (grab this Oct 19) but
>> this failed to build early to compile normal/main.c (gcc didn't find
>> some references to some grub_... struct and fnct)
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
> 
> 

Re: powerpc/sparc problems

[rubisher]

Bean wrote:
> On Mon, Oct 12, 2009 at 4:55 PM, Felix Zielcke <fzielcke@z-51.de> wrote:
>> David are you still there?
>> And also anyone who has access to a powerpc machine (and experience)?
>>
>> In Debian we the problem that the `__ashldi3' and `__bswapsi2' symbols
>> can't be found in the grub-ieee1275 build on powerpc and also sparc.
>>
>> Jordi already noticed this with the 1.96+20090721-4 IIRC and now other
>> people noticed this with 1.97~beta3
>> AFAICS there wasn't anything relevant changed on our side, so seems to
>> be a gcc issue.
>>
>> `__ashldi3' is listed in include/grub/powerpc/libgcc.h and `__bswapsi2'
>> in the sparc64 header.
>> But something has now changed that this isn't enough anymore, at least
>> in Debian.
>>
>> We used gcc 4.3.3 at the time Jordi noticed this and now switched to
>> gcc-4.4.1.
>>
>> And David we still have this sparc bug open, which I forwared to
>> grub-devel:
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538030
> 
> Hi,
> 
> Try my branch, it includes the libgcc functions in grub instead of
> rely on external library. It builds and run properly for
> powerpc-ieee1275 last time I check.
> 
Hello Mr bean ;<)

I reach to grab your git tree but even a fresh pull still failed to build from src as follow:
grub_emu-normal_main.o: In function `uitree_append':
/Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined reference to `grub_uitree_root'
/Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined reference to `grub_uitree_root'
/Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined reference to `grub_uitree_find'
/Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:179: undefined reference to `grub_uitree_create_node'
/Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:184: undefined reference to `grub_uitree_set_prop'
/Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:185: undefined reference to `grub_uitree_set_prop'
/Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:186: undefined reference to `grub_tree_add_child'
/Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:172: undefined reference to `grub_uitree_create_node'
/Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:175: undefined reference to `grub_tree_add_child'
collect2: ld returned 1 exit status
make[1]: *** [grub-emu] Error 1
make[1]: Leaving directory `/Sources/jso/Grub2.deb/grub2-git091021/build/grub-common'
make: *** [build/grub-common] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

Any idea/advise?

Tia,
	J.

Re: powerpc/sparc problems

[Bean]

On Thu, Oct 22, 2009 at 12:03 AM, rubisher <rubisher@scarlet.be> wrote:
> Bean wrote:
>>
>> On Mon, Oct 12, 2009 at 4:55 PM, Felix Zielcke <fzielcke@z-51.de> wrote:
>>>
>>> David are you still there?
>>> And also anyone who has access to a powerpc machine (and experience)?
>>>
>>> In Debian we the problem that the `__ashldi3' and `__bswapsi2' symbols
>>> can't be found in the grub-ieee1275 build on powerpc and also sparc.
>>>
>>> Jordi already noticed this with the 1.96+20090721-4 IIRC and now other
>>> people noticed this with 1.97~beta3
>>> AFAICS there wasn't anything relevant changed on our side, so seems to
>>> be a gcc issue.
>>>
>>> `__ashldi3' is listed in include/grub/powerpc/libgcc.h and `__bswapsi2'
>>> in the sparc64 header.
>>> But something has now changed that this isn't enough anymore, at least
>>> in Debian.
>>>
>>> We used gcc 4.3.3 at the time Jordi noticed this and now switched to
>>> gcc-4.4.1.
>>>
>>> And David we still have this sparc bug open, which I forwared to
>>> grub-devel:
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538030
>>
>> Hi,
>>
>> Try my branch, it includes the libgcc functions in grub instead of
>> rely on external library. It builds and run properly for
>> powerpc-ieee1275 last time I check.
>>
> Hello Mr bean ;<)
>
> I reach to grab your git tree but even a fresh pull still failed to build
> from src as follow:
> grub_emu-normal_main.o: In function `uitree_append':
> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined
> reference to `grub_uitree_root'
> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined
> reference to `grub_uitree_root'
> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined
> reference to `grub_uitree_find'
> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:179: undefined
> reference to `grub_uitree_create_node'
> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:184: undefined
> reference to `grub_uitree_set_prop'
> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:185: undefined
> reference to `grub_uitree_set_prop'
> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:186: undefined
> reference to `grub_tree_add_child'
> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:172: undefined
> reference to `grub_uitree_create_node'
> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:175: undefined
> reference to `grub_tree_add_child'
> collect2: ld returned 1 exit status
> make[1]: *** [grub-emu] Error 1
> make[1]: Leaving directory
> `/Sources/jso/Grub2.deb/grub2-git091021/build/grub-common'
> make: *** [build/grub-common] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>
> Any idea/advise?

Hi,

I forget to add some file for grub-emu previously, but it's fixed
already, pull the latest code.

-- 
Bean

gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/

Re: powerpc/sparc problems

[rubisher]

[-- Attachment #1: Type: text/plain, Size: 3949 bytes --]

> On Thu, Oct 22, 2009 at 12:03 AM, rubisher wrote:
> > Bean wrote:
> >>
> >> On Mon, Oct 12, 2009 at 4:55 PM, Felix Zielcke wrote:
> >>>
> >>> David are you still there?
> >>> And also anyone who has access to a powerpc machine (and experience)?
> >>>
> >>> In Debian we the problem that the `__ashldi3' and `__bswapsi2' symbols
> >>> can't be found in the grub-ieee1275 build on powerpc and also sparc.
> >>>
> >>> Jordi already noticed this with the 1.96+20090721-4 IIRC and now other
> >>> people noticed this with 1.97~beta3
> >>> AFAICS there wasn't anything relevant changed on our side, so seems to
> >>> be a gcc issue.
> >>>
> >>> `__ashldi3' is listed in include/grub/powerpc/libgcc.h and `__bswapsi2'
> >>> in the sparc64 header.
> >>> But something has now changed that this isn't enough anymore, at least
> >>> in Debian.
> >>>
> >>> We used gcc 4.3.3 at the time Jordi noticed this and now switched to
> >>> gcc-4.4.1.
> >>>
> >>> And David we still have this sparc bug open, which I forwared to
> >>> grub-devel:
> >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538030
> >>
> >> Hi,
> >>
> >> Try my branch, it includes the libgcc functions in grub instead of
> >> rely on external library. It builds and run properly for
> >> powerpc-ieee1275 last time I check.
> >>
> > Hello Mr bean ;<)
> >
> > I reach to grab your git tree but even a fresh pull still failed to build
> > from src as follow:
> > grub_emu-normal_main.o: In function `uitree_append':
> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined
> > reference to `grub_uitree_root'
> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined
> > reference to `grub_uitree_root'
> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined
> > reference to `grub_uitree_find'
> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:179: undefined
> > reference to `grub_uitree_create_node'
> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:184: undefined
> > reference to `grub_uitree_set_prop'
> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:185: undefined
> > reference to `grub_uitree_set_prop'
> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:186: undefined
> > reference to `grub_tree_add_child'
> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:172: undefined
> > reference to `grub_uitree_create_node'
> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:175: undefined
> > reference to `grub_tree_add_child'
> > collect2: ld returned 1 exit status
> > make[1]: *** [grub-emu] Error 1
> > make[1]: Leaving directory
> > `/Sources/jso/Grub2.deb/grub2-git091021/build/grub-common'
> > make: *** [build/grub-common] Error 2
> > dpkg-buildpackage: error: debian/rules build gave error exit status 2
> >
> > Any idea/advise?
>
> Hi,
>
> I forget to add some file for grub-emu previously, but it's fixed
> already, pull the latest code.
>
> --
> Bean
>
> gitgrub home: http://github.com/grub/grub/
> my fork page: http://github.com/bean123/grub/
>
Sorry I would have to be more accurate:
the git log said:
commit eb03e2575b2c0b1b4fd83f33a741f6fef3b93339
Author: Bean <bean123ch@gmail.com>
Date:   Wed Oct 21 01:11:27 2009 +0800

    Minor bug fix for parameter handling.

commit 8a3390f0164c89e8ae73884672556a9b31cbd766
Author: Bean <bean123ch@gmail.com>
Date:   Tue Oct 20 22:37:32 2009 +0800

    Support dialog and template, set maximum text mode for EFI.

Anyway, I remove all and clone it again:
git clone http://github.com/bean123/grub.git

copy this git tree in a working dir then run autogen.sh; mkdir build; cd build; ../configure; make
which still failed the same way.

Did i miss something???

Tx again,
    J.

_________________________________________
Scarlet Mobile, free subscription in combination with your Scarlet One or ADSL, visit http://www.scarlet.be/fr/mobile3g

[-- Attachment #2: Type: text/html, Size: 5860 bytes --]

Re: powerpc/sparc problems

[Bean]

On Thu, Oct 22, 2009 at 5:12 PM, rubisher <rubisher@scarlet.be> wrote:
>> On Thu, Oct 22, 2009 at 12:03 AM, rubisher wrote:
>> > Bean wrote:
>> >>
>> >> On Mon, Oct 12, 2009 at 4:55 PM, Felix Zielcke wrote:
>> >>>
>> >>> David are you still there?
>> >>> And also anyone who has access to a powerpc machine (and experience)?
>> >>>
>> >>> In Debian we the problem that the `__ashldi3' and `__bswapsi2' symbols
>> >>> can't be found in the grub-ieee1275 build on powerpc and also sparc.
>> >>>
>> >>> Jordi already noticed this with the 1.96+20090721-4 IIRC and now other
>> >>> people noticed this with 1.97~beta3
>> >>> AFAICS there wasn't anything relevant changed on our side, so seems to
>> >>> be a gcc issue.
>> >>>
>> >>> `__ashldi3' is listed in include/grub/powerpc/libgcc.h and
>> >>> `__bswapsi2'
>> >>> in the sparc64 header.
>> >>> But something has now changed that this isn't enough anymore, at least
>> >>> in Debian.
>> >>>
>> >>> We used gcc 4.3.3 at the time Jordi noticed this and now switched to
>> >>> gcc-4.4.1.
>> >>>
>> >>> And David we still have this sparc bug open, which I forwared to
>> >>> grub-devel:
>> >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538030
>> >>
>> >> Hi,
>> >>
>> >> Try my branch, it includes the libgcc functions in grub instead of
>> >> rely on external library. It builds and run properly for
>> >> powerpc-ieee1275 last time I check.
>> >>
>> > Hello Mr bean ;<)
>> >
>> > I reach to grab your git tree but even a fresh pull still failed to
>> > build
>> > from src as follow:
>> > grub_emu-normal_main.o: In function `uitree_append':
>> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined
>> > reference to `grub_uitree_root'
>> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined
>> > reference to `grub_uitree_root'
>> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined
>> > reference to `grub_uitree_find'
>> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:179: undefined
>> > reference to `grub_uitree_create_node'
>> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:184: undefined
>> > reference to `grub_uitree_set_prop'
>> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:185: undefined
>> > reference to `grub_uitree_set_prop'
>> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:186: undefined
>> > reference to `grub_tree_add_child'
>> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:172: undefined
>> > reference to `grub_uitree_create_node'
>> > /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:175: undefined
>> > reference to `grub_tree_add_child'
>> > collect2: ld returned 1 exit status
>> > make[1]: *** [grub-emu] Error 1
>> > make[1]: Leaving directory
>> > `/Sources/jso/Grub2.deb/grub2-git091021/build/grub-common'
>> > make: *** [build/grub-common] Error 2
>> > dpkg-buildpackage: error: debian/rules build gave error exit status 2
>> >
>> > Any idea/advise?
>>
>> Hi,
>>
>> I forget to add some file for grub-emu previously, but it's fixed
>> already, pull the latest code.
>>
>> --
>> Bean
>>
>> gitgrub home: http://github.com/grub/grub/
>> my fork page: http://github.com/bean123/grub/
>>
> Sorry I would have to be more accurate:
> the git log said:
> commit eb03e2575b2c0b1b4fd83f33a741f6fef3b93339
> Author: Bean <bean123ch@gmail.com>
> Date:   Wed Oct 21 01:11:27 2009 +0800
>
>     Minor bug fix for parameter handling.
>
> commit 8a3390f0164c89e8ae73884672556a9b31cbd766
> Author: Bean <bean123ch@gmail.com>
> Date:   Tue Oct 20 22:37:32 2009 +0800
>
>     Support dialog and template, set maximum text mode for EFI.
>
> Anyway, I remove all and clone it again:
> git clone http://github.com/bean123/grub.git
> copy this git tree in a working dir then run autogen.sh; mkdir build; cd
> build; ../configure; make
> which still failed the same way.
>
> Did i miss something???

Hi,

Oh I see, you use the powepc port, I only fix the x86 port. A quick
fix is to open conf/powerpc_ieee1275.rmk, find grub_emu_SOURCES and
add menu/tree.c and menu/uitree.c.


-- 
Bean

gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/

Re: powerpc/sparc problems

[rubisher]

Bean wrote:
> On Thu, Oct 22, 2009 at 5:12 PM, rubisher <rubisher@scarlet.be> wrote:
>>> On Thu, Oct 22, 2009 at 12:03 AM, rubisher wrote:
>>>> Bean wrote:
>>>>> On Mon, Oct 12, 2009 at 4:55 PM, Felix Zielcke wrote:
>>>>>> David are you still there?
>>>>>> And also anyone who has access to a powerpc machine (and experience)?
>>>>>>
>>>>>> In Debian we the problem that the `__ashldi3' and `__bswapsi2' symbols
>>>>>> can't be found in the grub-ieee1275 build on powerpc and also sparc.
>>>>>>
>>>>>> Jordi already noticed this with the 1.96+20090721-4 IIRC and now other
>>>>>> people noticed this with 1.97~beta3
>>>>>> AFAICS there wasn't anything relevant changed on our side, so seems to
>>>>>> be a gcc issue.
>>>>>>
>>>>>> `__ashldi3' is listed in include/grub/powerpc/libgcc.h and
>>>>>> `__bswapsi2'
>>>>>> in the sparc64 header.
>>>>>> But something has now changed that this isn't enough anymore, at least
>>>>>> in Debian.
>>>>>>
>>>>>> We used gcc 4.3.3 at the time Jordi noticed this and now switched to
>>>>>> gcc-4.4.1.
>>>>>>
>>>>>> And David we still have this sparc bug open, which I forwared to
>>>>>> grub-devel:
>>>>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538030
>>>>> Hi,
>>>>>
>>>>> Try my branch, it includes the libgcc functions in grub instead of
>>>>> rely on external library. It builds and run properly for
>>>>> powerpc-ieee1275 last time I check.
>>>>>
>>>> Hello Mr bean ;<)
>>>>
>>>> I reach to grab your git tree but even a fresh pull still failed to
>>>> build
>>>> from src as follow:
>>>> grub_emu-normal_main.o: In function `uitree_append':
>>>> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined
>>>> reference to `grub_uitree_root'
>>>> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined
>>>> reference to `grub_uitree_root'
>>>> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined
>>>> reference to `grub_uitree_find'
>>>> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:179: undefined
>>>> reference to `grub_uitree_create_node'
>>>> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:184: undefined
>>>> reference to `grub_uitree_set_prop'
>>>> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:185: undefined
>>>> reference to `grub_uitree_set_prop'
>>>> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:186: undefined
>>>> reference to `grub_tree_add_child'
>>>> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:172: undefined
>>>> reference to `grub_uitree_create_node'
>>>> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:175: undefined
>>>> reference to `grub_tree_add_child'
>>>> collect2: ld returned 1 exit status
>>>> make[1]: *** [grub-emu] Error 1
>>>> make[1]: Leaving directory
>>>> `/Sources/jso/Grub2.deb/grub2-git091021/build/grub-common'
>>>> make: *** [build/grub-common] Error 2
>>>> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>>>>
>>>> Any idea/advise?
>>> Hi,
>>>
>>> I forget to add some file for grub-emu previously, but it's fixed
>>> already, pull the latest code.
>>>
>>> --
>>> Bean
>>>
>>> gitgrub home: http://github.com/grub/grub/
>>> my fork page: http://github.com/bean123/grub/
>>>
>> Sorry I would have to be more accurate:
>> the git log said:
>> commit eb03e2575b2c0b1b4fd83f33a741f6fef3b93339
>> Author: Bean <bean123ch@gmail.com>
>> Date:   Wed Oct 21 01:11:27 2009 +0800
>>
>>     Minor bug fix for parameter handling.
>>
>> commit 8a3390f0164c89e8ae73884672556a9b31cbd766
>> Author: Bean <bean123ch@gmail.com>
>> Date:   Tue Oct 20 22:37:32 2009 +0800
>>
>>     Support dialog and template, set maximum text mode for EFI.
>>
>> Anyway, I remove all and clone it again:
>> git clone http://github.com/bean123/grub.git
>> copy this git tree in a working dir then run autogen.sh; mkdir build; cd
>> build; ../configure; make
>> which still failed the same way.
>>
>> Did i miss something???
> 
> Hi,
> 
> Oh I see, you use the powepc port, I only fix the x86 port. A quick
> fix is to open conf/powerpc_ieee1275.rmk, find grub_emu_SOURCES and
> add menu/tree.c and menu/uitree.c.
> 
> 
Thanks that's help to continue and to finish the build but failed to assemle the image:
/usr/bin/grub-mkelfimage --directory=/usr/lib/grub/powerpc-ieee1275 --output=/boot/grub/grub fat part_msdos
grub-mkimage: error: unresolved symbol _savegpr_29

But if I manage to rebuild it with -O0 (or -O2), I reach to boot it ;-).
But I guess there isn't enough module loaded because at grub prompt, it didn't find any disk?

That said by default the dpkg build the kern.img as follow:

# /usr/bin/grub-mkelfimage --directory=/usr/lib/grub/powerpc-ieee1275 --output=/boot/grub/grub fat part_msdos

and create for me a grub.cfg with severall menuentries like:
### BEGIN /etc/grub.d/10_linux ###
menuentry "Debian GNU/Linux, with Linux 2.6.30-2-powerpc64" {
         insmod ext2
         set root=(hd1,3)
         search --no-floppy --fs-uuid --set 16ef0754-c845-46e9-a948-b9669ee68329
         linux   /vmlinux-2.6.30-2-powerpc64 root=UUID=3c51c43e-63a7-4ff1-9b1c-cf98addcb7ed ro  quiet
         initrd  /initrd.img-2.6.30-2-powerpc64
}

Given those 2 elements, I presume that the fact grub2 isn't able to find any disk is because it lakes of one or more module 
either in the build image or in menuentry (I just started with grub2 2 weeks ago so please appology if don't yet understand 
all details)?

As it seems that you have some experience with powerpc, may be can you advise me with some your tips (how did you build your 
image, a sample of one your menuentry?): I also tried to follow recipe of <http://grub.enbug.org/TestingOnPowerPC> i.e.
# cd /usr/lib/grub/powerpc-ieee1275 (where *.mod stand)
# /usr/bin/grub-mkelfimage -n --directory=/usr/lib/grub/powerpc-ieee1275 --output=/boot/grub/grubof.modules *.mod
(-n for pseries) but this image sadely make panicing ofs:
DEFAULT CATCH!, exception-handler=fff00300
at   %SRR0: 0000000000c3c25c   %SRR1: 800000000000b002
Call History
------------
@  - c3c1f0
close-package  - c58060
(poplocals)  - c3a758
(init-program)  - c7e298
boot  - c7ec7c
evaluate  - c4a638
invalid pointer - d83655
invalid pointer - f
invalid pointer - f
catch  - c38fe8
bt-task-boot-on-this  - d140d8
(poplocals)  - c3a758
catch  - c38fe8
execute-device-method  - c58bcc
(poplocals)  - c3a758
(select-boot-seq)  - c59ba4

Client's Fix Pt Regs:
Client's Fix Pt Regs:
  00 00100000000001f4 ffffffffffffffff 00000000deadbeef fffffffffffffffc
  04 0000000000000000 0000000000000000 0000000000000000 0000000000000001
  08 0000000000001000 0000030002001000 0000000000000003 0000000000007000
  0c 0000000022800000 0000000000c17100 0000000000c18000 000000000009c4b0
  10 0000000000db8c20 0000000000db8939 0000000000c57d80 0000000000c58060
  14 0000000000000000 ffffffffffffffff 0000000000000000 0000000000000000
  18 0000000000c13000 0000000000c38000 0000000000c14d40 0000000000c16ec0
  1c 0000000000c20000 0000000000c3fdf0 0000000000c11ea0 0000000000c10fa8
Special Regs:
     %IV: 00000300     %CR: 84800000    %XER: 20000008  %DSISR: 08000000
   %SRR0: 0000000000c3c25c   %SRR1: 800000000000b002
     %LR: 0000000000c3c1f0    %CTR: 0000000000000000
    %DAR: ffffffffffffffff
Virtual PID = 0
  ofdbg

At this point I am worry that the change of optimization compile option (-Os -> -O0) break something or am I facing to some 
issue related to my ofs or something else in config file (e.g. I just figure out that I didn't change my grub.cfg with the 
usage of lasetest describe image grubof.modules: I didn't remove the 'insmod ext2', thought?)

Thanks again for all,
	J.

PS: This boxe is a P510 with latest IBM system firmware SF240_382

Re: powerpc/sparc problems

[Bean]

On Sat, Oct 24, 2009 at 4:34 AM, rubisher <rubisher@scarlet.be> wrote:
> Bean wrote:
>>
>> On Thu, Oct 22, 2009 at 5:12 PM, rubisher <rubisher@scarlet.be> wrote:
>>>>
>>>> On Thu, Oct 22, 2009 at 12:03 AM, rubisher wrote:
>>>>>
>>>>> Bean wrote:
>>>>>>
>>>>>> On Mon, Oct 12, 2009 at 4:55 PM, Felix Zielcke wrote:
>>>>>>>
>>>>>>> David are you still there?
>>>>>>> And also anyone who has access to a powerpc machine (and experience)?
>>>>>>>
>>>>>>> In Debian we the problem that the `__ashldi3' and `__bswapsi2'
>>>>>>> symbols
>>>>>>> can't be found in the grub-ieee1275 build on powerpc and also sparc.
>>>>>>>
>>>>>>> Jordi already noticed this with the 1.96+20090721-4 IIRC and now
>>>>>>> other
>>>>>>> people noticed this with 1.97~beta3
>>>>>>> AFAICS there wasn't anything relevant changed on our side, so seems
>>>>>>> to
>>>>>>> be a gcc issue.
>>>>>>>
>>>>>>> `__ashldi3' is listed in include/grub/powerpc/libgcc.h and
>>>>>>> `__bswapsi2'
>>>>>>> in the sparc64 header.
>>>>>>> But something has now changed that this isn't enough anymore, at
>>>>>>> least
>>>>>>> in Debian.
>>>>>>>
>>>>>>> We used gcc 4.3.3 at the time Jordi noticed this and now switched to
>>>>>>> gcc-4.4.1.
>>>>>>>
>>>>>>> And David we still have this sparc bug open, which I forwared to
>>>>>>> grub-devel:
>>>>>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538030
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Try my branch, it includes the libgcc functions in grub instead of
>>>>>> rely on external library. It builds and run properly for
>>>>>> powerpc-ieee1275 last time I check.
>>>>>>
>>>>> Hello Mr bean ;<)
>>>>>
>>>>> I reach to grab your git tree but even a fresh pull still failed to
>>>>> build
>>>>> from src as follow:
>>>>> grub_emu-normal_main.o: In function `uitree_append':
>>>>> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined
>>>>> reference to `grub_uitree_root'
>>>>> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined
>>>>> reference to `grub_uitree_root'
>>>>> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined
>>>>> reference to `grub_uitree_find'
>>>>> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:179: undefined
>>>>> reference to `grub_uitree_create_node'
>>>>> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:184: undefined
>>>>> reference to `grub_uitree_set_prop'
>>>>> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:185: undefined
>>>>> reference to `grub_uitree_set_prop'
>>>>> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:186: undefined
>>>>> reference to `grub_tree_add_child'
>>>>> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:172: undefined
>>>>> reference to `grub_uitree_create_node'
>>>>> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:175: undefined
>>>>> reference to `grub_tree_add_child'
>>>>> collect2: ld returned 1 exit status
>>>>> make[1]: *** [grub-emu] Error 1
>>>>> make[1]: Leaving directory
>>>>> `/Sources/jso/Grub2.deb/grub2-git091021/build/grub-common'
>>>>> make: *** [build/grub-common] Error 2
>>>>> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>>>>>
>>>>> Any idea/advise?
>>>>
>>>> Hi,
>>>>
>>>> I forget to add some file for grub-emu previously, but it's fixed
>>>> already, pull the latest code.
>>>>
>>>> --
>>>> Bean
>>>>
>>>> gitgrub home: http://github.com/grub/grub/
>>>> my fork page: http://github.com/bean123/grub/
>>>>
>>> Sorry I would have to be more accurate:
>>> the git log said:
>>> commit eb03e2575b2c0b1b4fd83f33a741f6fef3b93339
>>> Author: Bean <bean123ch@gmail.com>
>>> Date:   Wed Oct 21 01:11:27 2009 +0800
>>>
>>>    Minor bug fix for parameter handling.
>>>
>>> commit 8a3390f0164c89e8ae73884672556a9b31cbd766
>>> Author: Bean <bean123ch@gmail.com>
>>> Date:   Tue Oct 20 22:37:32 2009 +0800
>>>
>>>    Support dialog and template, set maximum text mode for EFI.
>>>
>>> Anyway, I remove all and clone it again:
>>> git clone http://github.com/bean123/grub.git
>>> copy this git tree in a working dir then run autogen.sh; mkdir build; cd
>>> build; ../configure; make
>>> which still failed the same way.
>>>
>>> Did i miss something???
>>
>> Hi,
>>
>> Oh I see, you use the powepc port, I only fix the x86 port. A quick
>> fix is to open conf/powerpc_ieee1275.rmk, find grub_emu_SOURCES and
>> add menu/tree.c and menu/uitree.c.
>>
>>
> Thanks that's help to continue and to finish the build but failed to assemle
> the image:
> /usr/bin/grub-mkelfimage --directory=/usr/lib/grub/powerpc-ieee1275
> --output=/boot/grub/grub fat part_msdos
> grub-mkimage: error: unresolved symbol _savegpr_29
>
> But if I manage to rebuild it with -O0 (or -O2), I reach to boot it ;-).
> But I guess there isn't enough module loaded because at grub prompt, it
> didn't find any disk?
>
> That said by default the dpkg build the kern.img as follow:
>
> # /usr/bin/grub-mkelfimage --directory=/usr/lib/grub/powerpc-ieee1275
> --output=/boot/grub/grub fat part_msdos
>
> and create for me a grub.cfg with severall menuentries like:
> ### BEGIN /etc/grub.d/10_linux ###
> menuentry "Debian GNU/Linux, with Linux 2.6.30-2-powerpc64" {
>        insmod ext2
>        set root=(hd1,3)
>        search --no-floppy --fs-uuid --set
> 16ef0754-c845-46e9-a948-b9669ee68329
>        linux   /vmlinux-2.6.30-2-powerpc64
> root=UUID=3c51c43e-63a7-4ff1-9b1c-cf98addcb7ed ro  quiet
>        initrd  /initrd.img-2.6.30-2-powerpc64
> }
>
> Given those 2 elements, I presume that the fact grub2 isn't able to find any
> disk is because it lakes of one or more module either in the build image or
> in menuentry (I just started with grub2 2 weeks ago so please appology if
> don't yet understand all details)?
>
> As it seems that you have some experience with powerpc, may be can you
> advise me with some your tips (how did you build your image, a sample of one
> your menuentry?): I also tried to follow recipe of
> <http://grub.enbug.org/TestingOnPowerPC> i.e.
> # cd /usr/lib/grub/powerpc-ieee1275 (where *.mod stand)
> # /usr/bin/grub-mkelfimage -n --directory=/usr/lib/grub/powerpc-ieee1275
> --output=/boot/grub/grubof.modules *.mod
> (-n for pseries) but this image sadely make panicing ofs:
> DEFAULT CATCH!, exception-handler=fff00300
> at   %SRR0: 0000000000c3c25c   %SRR1: 800000000000b002
> Call History
> ------------
> @  - c3c1f0
> close-package  - c58060
> (poplocals)  - c3a758
> (init-program)  - c7e298
> boot  - c7ec7c
> evaluate  - c4a638
> invalid pointer - d83655
> invalid pointer - f
> invalid pointer - f
> catch  - c38fe8
> bt-task-boot-on-this  - d140d8
> (poplocals)  - c3a758
> catch  - c38fe8
> execute-device-method  - c58bcc
> (poplocals)  - c3a758
> (select-boot-seq)  - c59ba4
>
> Client's Fix Pt Regs:
> Client's Fix Pt Regs:
>  00 00100000000001f4 ffffffffffffffff 00000000deadbeef fffffffffffffffc
>  04 0000000000000000 0000000000000000 0000000000000000 0000000000000001
>  08 0000000000001000 0000030002001000 0000000000000003 0000000000007000
>  0c 0000000022800000 0000000000c17100 0000000000c18000 000000000009c4b0
>  10 0000000000db8c20 0000000000db8939 0000000000c57d80 0000000000c58060
>  14 0000000000000000 ffffffffffffffff 0000000000000000 0000000000000000
>  18 0000000000c13000 0000000000c38000 0000000000c14d40 0000000000c16ec0
>  1c 0000000000c20000 0000000000c3fdf0 0000000000c11ea0 0000000000c10fa8
> Special Regs:
>    %IV: 00000300     %CR: 84800000    %XER: 20000008  %DSISR: 08000000
>  %SRR0: 0000000000c3c25c   %SRR1: 800000000000b002
>    %LR: 0000000000c3c1f0    %CTR: 0000000000000000
>   %DAR: ffffffffffffffff
> Virtual PID = 0
>  ofdbg
>
> At this point I am worry that the change of optimization compile option (-Os
> -> -O0) break something or am I facing to some issue related to my ofs or
> something else in config file (e.g. I just figure out that I didn't change
> my grub.cfg with the usage of lasetest describe image grubof.modules: I
> didn't remove the 'insmod ext2', thought?)

Hi,

Don't include all modules, the boot image seems to be broken when it
exceed certain size. The following list should be enough:

minicmd fat part_msdos normal sh ls linux

in the grub shell, use ls command to list detected devices.

-- 
Bean

gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/

Re: powerpc/sparc problems

[rubisher]

Bean wrote:
> On Sat, Oct 24, 2009 at 4:34 AM, rubisher <rubisher@scarlet.be> wrote:
[snip]
>>
>> As it seems that you have some experience with powerpc, may be can you
>> advise me with some your tips (how did you build your image, a sample of one
>> your menuentry?): I also tried to follow recipe of
>> <http://grub.enbug.org/TestingOnPowerPC> i.e.
>> # cd /usr/lib/grub/powerpc-ieee1275 (where *.mod stand)
>> # /usr/bin/grub-mkelfimage -n --directory=/usr/lib/grub/powerpc-ieee1275
>> --output=/boot/grub/grubof.modules *.mod
>> (-n for pseries) but this image sadely make panicing ofs:
>> DEFAULT CATCH!, exception-handler=fff00300
>> at   %SRR0: 0000000000c3c25c   %SRR1: 800000000000b002
>> Call History
>> ------------
>> @  - c3c1f0
>> close-package  - c58060
>> (poplocals)  - c3a758
>> (init-program)  - c7e298
>> boot  - c7ec7c
>> evaluate  - c4a638
>> invalid pointer - d83655
>> invalid pointer - f
>> invalid pointer - f
>> catch  - c38fe8
>> bt-task-boot-on-this  - d140d8
>> (poplocals)  - c3a758
>> catch  - c38fe8
>> execute-device-method  - c58bcc
>> (poplocals)  - c3a758
>> (select-boot-seq)  - c59ba4
>>
>> Client's Fix Pt Regs:
>> Client's Fix Pt Regs:
>>  00 00100000000001f4 ffffffffffffffff 00000000deadbeef fffffffffffffffc
>>  04 0000000000000000 0000000000000000 0000000000000000 0000000000000001
>>  08 0000000000001000 0000030002001000 0000000000000003 0000000000007000
>>  0c 0000000022800000 0000000000c17100 0000000000c18000 000000000009c4b0
>>  10 0000000000db8c20 0000000000db8939 0000000000c57d80 0000000000c58060
>>  14 0000000000000000 ffffffffffffffff 0000000000000000 0000000000000000
>>  18 0000000000c13000 0000000000c38000 0000000000c14d40 0000000000c16ec0
>>  1c 0000000000c20000 0000000000c3fdf0 0000000000c11ea0 0000000000c10fa8
>> Special Regs:
>>    %IV: 00000300     %CR: 84800000    %XER: 20000008  %DSISR: 08000000
>>  %SRR0: 0000000000c3c25c   %SRR1: 800000000000b002
>>    %LR: 0000000000c3c1f0    %CTR: 0000000000000000
>>   %DAR: ffffffffffffffff
>> Virtual PID = 0
>>  ofdbg
>>
>> At this point I am worry that the change of optimization compile option (-Os
>> -> -O0) break something or am I facing to some issue related to my ofs or
>> something else in config file (e.g. I just figure out that I didn't change
>> my grub.cfg with the usage of lasetest describe image grubof.modules: I
>> didn't remove the 'insmod ext2', thought?)
> 
> Hi,
> 
> Don't include all modules, the boot image seems to be broken when it
> exceed certain size. The following list should be enough:
> 
> minicmd fat part_msdos normal sh ls linux
> 
> in the grub shell, use ls command to list detected devices.
> 
Thanks;

at least i didn't encountered anymore ofs panic but in grub rescue sheel 'ls' just return an empty line;
I can just grab 'lsmod' info:
sh:grub> lsmod
Name    Ref Count       Dependencies
linux   1               boot,elf
elf     2               gzio
gzio    3
ls      1               normal,extcmd
extcmd  2
sh      1               normal
normal  4               boot
boot    6
part_msdos      1
fat     1
minicmd 1

but if I try to add another module (e.g. scsi or what else) it always respond:
"error: invalid arch independent ELF magic"

Re: powerpc/sparc problems

[Bean]

On Sun, Oct 25, 2009 at 11:22 PM, rubisher <rubisher@scarlet.be> wrote:
> at least i didn't encountered anymore ofs panic but in grub rescue sheel
> 'ls' just return an empty line;
> I can just grab 'lsmod' info:
> sh:grub> lsmod
> Name    Ref Count       Dependencies
> linux   1               boot,elf
> elf     2               gzio
> gzio    3
> ls      1               normal,extcmd
> extcmd  2
> sh      1               normal
> normal  4               boot
> boot    6
> part_msdos      1
> fat     1
> minicmd 1
>
> but if I try to add another module (e.g. scsi or what else) it always
> respond:
> "error: invalid arch independent ELF magic"

Hi,

You shouldn't need scsi, which is used by ata module to access pci
bus, but openfirmware would export the boot disk for you.

Use these command:

set debug=disk
ls

This should print some debug information in grub console.

-- 
Bean

gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/

Re: powerpc/sparc problems

[rubisher]

Bean wrote:
> On Sun, Oct 25, 2009 at 11:22 PM, rubisher <rubisher@scarlet.be> wrote:
[snip]
> 
> Hi,
> 
> You shouldn't need scsi, which is used by ata module to access pci
> bus, but openfirmware would export the boot disk for you.
> 
> Use these command:
> 
> set debug=disk
> ls
> 
> This should print some debug information in grub console.
> 
I try to do my best to clean up as much as possible info collected:

Elapsed time since release of system processors: 149810 mins 22 secs
Welcome to GRUB!

Entering rescue mode...

<<< I first noticed that grub fallback immidiately in rescue mode?

                             GNU GRUB  version 1.97+experimental

cursor-on, unknown word [ Minimal BASH-like line editing is supported. For the first word, TAB
    lists possible command completions. Anywhere else TAB lists possible
    device/file completions. ]

cursor-off, unknown word

<<< I don't know yet what those 'cursor-on/off, unknown word' means?

                             GNU GRUB  version 1.97+experimental

sh:grub> ls
SRCTREE/kern/disk.c:245: Opening `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:173: Opening `/vdevice/v-scsi@30000016/disk@8100000000000000:0'.
SRCTREE/disk/ieee1275/ofdisk.c:183: Opened `/vdevice/v-scsi@30000016/disk@8100000000000000:0' as handle 0x19ff180.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x0, size 0x8, buf 0x3a2640.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x20, size 0x8, buf 0x1c0dbd0.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x188, size 0x8, buf 0x1c26980.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
[snip]
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x190, size 0x8, buf 0x1c0dc30.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
[snip]
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x458, size 0x8, buf 0x1c09940.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
[snip]
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x460, size 0x8, buf 0x1c09940.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
[snip]
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x468, size 0x8, buf 0x1c09940.
SRCTREE/kern/disk.c:333: Closing `/vdevice/v-scsi@30000016/disk@8100000000000000,1'.
SRCTREE/disk/ieee1275/ofdisk.c:226: Closing handle 0x19ff180.
SRCTREE/kern/disk.c:245: Opening `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:173: Opening `/vdevice/v-scsi@30000016/disk@8100000000000000:0'.
SRCTREE/disk/ieee1275/ofdisk.c:183: Opened `/vdevice/v-scsi@30000016/disk@8100000000000000:0' as handle 0x19ff180.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x0, size 0x8, buf 0x1c26980.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x20, size 0x8, buf 0x1c06910.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x188, size 0x8, buf 0x1c048f0.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
[snip]
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x190, size 0x8, buf 0x1c26980.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
[snip]
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x2c8, size 0x8, buf 0x1c26980.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
[snip]
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x2d0, size 0x8, buf 0x1c26980.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
[snip]
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x2d8, size 0x8, buf 0x1c26980.
SRCTREE/kern/disk.c:333: Closing `/vdevice/v-scsi@30000016/disk@8100000000000000,1'.
SRCTREE/disk/ieee1275/ofdisk.c:226: Closing handle 0x19ff180.
SRCTREE/disk/ieee1275/ofdisk.c:82: disk name = ibm, sp
SRCTREE/disk/ieee1275/ofdisk.c:82: disk name = network
SRCTREE/disk/ieee1275/ofdisk.c:82: disk name = net
SRCTREE/disk/ieee1275/ofdisk.c:82: disk name = network1
SRCTREE/disk/ieee1275/ofdisk.c:82: disk name = scsi
SRCTREE/disk/ieee1275/ofdisk.c:82: disk name = nvram
SRCTREE/disk/ieee1275/ofdisk.c:82: disk name = rtc
SRCTREE/disk/ieee1275/ofdisk.c:82: disk name = screen

rem: `/vdevice/v-scsi@30000016/disk@8100000000000000,1' this is well the string put in nvram
(I try also to rm ',1' at the end but that doesn't help?)

tia for further help, ...

That said, on my ibm p5 (I haven't access to any other system booting with different ofs), I have to install grub on a 
dedicated fs (as far as I understand, I can choose between hfs and fat, here I select fat) as follow:

(p5_sid)root@p5tst001:~# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sdb6              2015808   1986772     29036  99% /
/dev/sdb3               247919    161597     86322  66% /boot
/dev/sdb1                23337     21302      2035  92% /boot/grub
[snip]

I copied my vmlinux and it's related initrd files in /boot/grub and use a simplified grub.cfg:
set timeout=5

menuentry "Debian GNU/Linux, with Linux 2.6.30-2-powerpc64" {
         linux   /vmlinux-2.6.30-2-powerpc64 root=UUID=3c51c43e-63a7-4ff1-9b1c-cf98addcb7ed ro sysrq=1 insmod=sym53c8xx 
insmod=ipr quiet
         initrd  /initrd.img-2.6.30-2-powerpc64
}

Ok, it always fall in rescue mode but shows me well a single line menu "Debian GNU/Linux, with Linux 2.6.30-2-powerpc64" and 
then my debian installation boot well ;<)
That's a bit like with grub legacy on my i386 where grub stand in the same fs as boot but in a subdir

but that's just a tips and not what we want to do?
(afaik my reading told of max size of about 24Mb for /boot/grub fs, so it wouldn't be able to contains a lot of kernel)

Thanks in advance for additional feedback,
	J.

PS: those latest test was made with latest debian pkg src of grub2_1.97+experimental.20091026-1.dsc without optimization (-O0)

Re: powerpc/sparc problems

[Felix Zielcke]

Am Montag, den 12.10.2009, 10:55 +0200 schrieb Felix Zielcke:
> David are you still there?
> And also anyone who has access to a powerpc machine (and experience)?
> 
> In Debian we the problem that the `__ashldi3' and `__bswapsi2' symbols
> can't be found in the grub-ieee1275 build on powerpc and also sparc.

Ok the internal gcc symbols for sparc have been fixed now.
But now there's another problem on sparc:

  ok boot
  Boot device: disk  File and args:                                     
  GRUB Illegal Instruction
  ok 

-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Re: powerpc/sparc problems

[David Miller]

From: Felix Zielcke <fzielcke@z-51.de>
Date: Wed, 28 Oct 2009 11:24:58 +0100

> Am Montag, den 12.10.2009, 10:55 +0200 schrieb Felix Zielcke:
>> David are you still there?
>> And also anyone who has access to a powerpc machine (and experience)?
>> 
>> In Debian we the problem that the `__ashldi3' and `__bswapsi2' symbols
>> can't be found in the grub-ieee1275 build on powerpc and also sparc.
> 
> Ok the internal gcc symbols for sparc have been fixed now.
> But now there's another problem on sparc:
> 
>   ok boot
>   Boot device: disk  File and args:                                     
>   GRUB Illegal Instruction
>   ok 

Like I said, I won't be able to look into these kinds of things
for at least a month or so and I doubt anyone else here has the
sparc knowledge necessary to help you diagnose this.

Sorry.

help need for powerpc issue

[rubisher]

Hello all,

Is some off you could advise me at some starting point to investigate this issue encountered to boot a lpar.
(I just take the opportunity to still have access to such platform to help comunity)


Bean wrote:
> On Sun, Oct 25, 2009 at 11:22 PM, rubisher <rubisher@scarlet.be> wrote:
[snip]
> 
> Hi,
> 
> You shouldn't need scsi, which is used by ata module to access pci
> bus, but openfirmware would export the boot disk for you.
> 
> Use these command:
> 
> set debug=disk
> ls
> 
> This should print some debug information in grub console.
> 
I try to do my best to clean up as much as possible info collected:

Elapsed time since release of system processors: 149810 mins 22 secs
Welcome to GRUB!

Entering rescue mode...

<<< I first noticed that grub fallback immidiately in rescue mode?

                             GNU GRUB  version 1.97+experimental

cursor-on, unknown word [ Minimal BASH-like line editing is supported. For the first word, TAB
    lists possible command completions. Anywhere else TAB lists possible
    device/file completions. ]

cursor-off, unknown word

<<< Well I already sent a proposal to fix annoying this "cursor-off, unknown word"

                             GNU GRUB  version 1.97+experimental

sh:grub> ls
SRCTREE/kern/disk.c:245: Opening `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:173: Opening `/vdevice/v-scsi@30000016/disk@8100000000000000:0'.
SRCTREE/disk/ieee1275/ofdisk.c:183: Opened `/vdevice/v-scsi@30000016/disk@8100000000000000:0' as handle 0x19ff180.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x0, size 0x8, buf 0x3a2640.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x20, size 0x8, buf 0x1c0dbd0.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x188, size 0x8, buf 0x1c26980.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
[snip]
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x190, size 0x8, buf 0x1c0dc30.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
[snip]
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x458, size 0x8, buf 0x1c09940.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
[snip]
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x460, size 0x8, buf 0x1c09940.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
[snip]
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x468, size 0x8, buf 0x1c09940.
SRCTREE/kern/disk.c:333: Closing `/vdevice/v-scsi@30000016/disk@8100000000000000,1'.
SRCTREE/disk/ieee1275/ofdisk.c:226: Closing handle 0x19ff180.
SRCTREE/kern/disk.c:245: Opening `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:173: Opening `/vdevice/v-scsi@30000016/disk@8100000000000000:0'.
SRCTREE/disk/ieee1275/ofdisk.c:183: Opened `/vdevice/v-scsi@30000016/disk@8100000000000000:0' as handle 0x19ff180.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x0, size 0x8, buf 0x1c26980.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x20, size 0x8, buf 0x1c06910.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x188, size 0x8, buf 0x1c048f0.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
[snip]
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x190, size 0x8, buf 0x1c26980.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
[snip]
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x2c8, size 0x8, buf 0x1c26980.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
[snip]
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x2d0, size 0x8, buf 0x1c26980.
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
[snip]
SRCTREE/kern/disk.c:389: Reading `/vdevice/v-scsi@30000016/disk@8100000000000000,1'...
SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x2d8, size 0x8, buf 0x1c26980.
SRCTREE/kern/disk.c:333: Closing `/vdevice/v-scsi@30000016/disk@8100000000000000,1'.
SRCTREE/disk/ieee1275/ofdisk.c:226: Closing handle 0x19ff180.
SRCTREE/disk/ieee1275/ofdisk.c:82: disk name = ibm, sp
SRCTREE/disk/ieee1275/ofdisk.c:82: disk name = network
SRCTREE/disk/ieee1275/ofdisk.c:82: disk name = net
SRCTREE/disk/ieee1275/ofdisk.c:82: disk name = network1
SRCTREE/disk/ieee1275/ofdisk.c:82: disk name = scsi
SRCTREE/disk/ieee1275/ofdisk.c:82: disk name = nvram
SRCTREE/disk/ieee1275/ofdisk.c:82: disk name = rtc
SRCTREE/disk/ieee1275/ofdisk.c:82: disk name = screen

rem: `/vdevice/v-scsi@30000016/disk@8100000000000000,1' this is well the string put in nvram
(I try also to rm ',1' at the end but that doesn't help?)

That said, on my ibm p5 (I haven't access to any other system booting with different ofs), I have to install grub on a
dedicated fs (as far as I understand, I can choose between hfs and fat, here I select fat) as follow:

(p5_sid)root@p5tst001:~# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sdb6              2015808   1986772     29036  99% /
/dev/sdb3               247919    161597     86322  66% /boot
/dev/sdb1                23337     21302      2035  92% /boot/grub
[snip]

I copied my vmlinux and it's related initrd files in /boot/grub and use a simplified grub.cfg:
set timeout=5

menuentry "Debian GNU/Linux, with Linux 2.6.30-2-powerpc64" {
         linux   /vmlinux-2.6.30-2-powerpc64 root=UUID=3c51c43e-63a7-4ff1-9b1c-cf98addcb7ed ro sysrq=1 insmod=sym53c8xx
insmod=ipr quiet
         initrd  /initrd.img-2.6.30-2-powerpc64
}

Ok, it always fall in rescue mode but shows me well a single line menu "Debian GNU/Linux, with Linux 2.6.30-2-powerpc64" and
then my debian installation boot well ;<)
That's a bit like with grub legacy on my i386 where grub stand in the same fs as boot but in a subdir

but that's just a tips and not what we want to do?
(afaik my reading told of max size of about 24Mb for /boot/grub fs, so it wouldn't be able to contains a lot of kernel)

Thanks in advance for additional feedback,
	J.

PS: those latest test was made with latest debian pkg src of grub2_1.97+experimental.20091026-1.dsc without optimization (-O0)