Re: powerpc/sparc problems
From: Felix Zielcke fziel...@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. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
Bean wrote: On Sun, Oct 25, 2009 at 11:22 PM, rubisher rubis...@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-s...@3016/d...@8100,1'... SRCTREE/disk/ieee1275/ofdisk.c:173: Opening `/vdevice/v-s...@3016/d...@8100:0'. SRCTREE/disk/ieee1275/ofdisk.c:183: Opened `/vdevice/v-s...@3016/d...@8100:0' as handle 0x19ff180. SRCTREE/kern/disk.c:389: Reading `/vdevice/v-s...@3016/d...@8100,1'... SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x0, size 0x8, buf 0x3a2640. SRCTREE/kern/disk.c:389: Reading `/vdevice/v-s...@3016/d...@8100,1'... SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x20, size 0x8, buf 0x1c0dbd0. SRCTREE/kern/disk.c:389: Reading `/vdevice/v-s...@3016/d...@8100,1'... SRCTREE/kern/disk.c:389: Reading `/vdevice/v-s...@3016/d...@8100,1'... SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x188, size 0x8, buf 0x1c26980. SRCTREE/kern/disk.c:389: Reading `/vdevice/v-s...@3016/d...@8100,1'... [snip] SRCTREE/kern/disk.c:389: Reading `/vdevice/v-s...@3016/d...@8100,1'... SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x190, size 0x8, buf 0x1c0dc30. SRCTREE/kern/disk.c:389: Reading `/vdevice/v-s...@3016/d...@8100,1'... [snip] SRCTREE/kern/disk.c:389: Reading `/vdevice/v-s...@3016/d...@8100,1'... SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x458, size 0x8, buf 0x1c09940. SRCTREE/kern/disk.c:389: Reading `/vdevice/v-s...@3016/d...@8100,1'... [snip] SRCTREE/kern/disk.c:389: Reading `/vdevice/v-s...@3016/d...@8100,1'... SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x460, size 0x8, buf 0x1c09940. SRCTREE/kern/disk.c:389: Reading `/vdevice/v-s...@3016/d...@8100,1'... [snip] SRCTREE/kern/disk.c:389: Reading `/vdevice/v-s...@3016/d...@8100,1'... SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x468, size 0x8, buf 0x1c09940. SRCTREE/kern/disk.c:333: Closing `/vdevice/v-s...@3016/d...@8100,1'. SRCTREE/disk/ieee1275/ofdisk.c:226: Closing handle 0x19ff180. SRCTREE/kern/disk.c:245: Opening `/vdevice/v-s...@3016/d...@8100,1'... SRCTREE/disk/ieee1275/ofdisk.c:173: Opening `/vdevice/v-s...@3016/d...@8100:0'. SRCTREE/disk/ieee1275/ofdisk.c:183: Opened `/vdevice/v-s...@3016/d...@8100:0' as handle 0x19ff180. SRCTREE/kern/disk.c:389: Reading `/vdevice/v-s...@3016/d...@8100,1'... SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x0, size 0x8, buf 0x1c26980. SRCTREE/kern/disk.c:389: Reading `/vdevice/v-s...@3016/d...@8100,1'... SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x20, size 0x8, buf 0x1c06910. SRCTREE/kern/disk.c:389: Reading `/vdevice/v-s...@3016/d...@8100,1'... SRCTREE/kern/disk.c:389: Reading `/vdevice/v-s...@3016/d...@8100,1'... SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x188, size 0x8, buf 0x1c048f0. SRCTREE/kern/disk.c:389: Reading `/vdevice/v-s...@3016/d...@8100,1'... [snip] SRCTREE/kern/disk.c:389: Reading `/vdevice/v-s...@3016/d...@8100,1'... SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x190, size 0x8, buf 0x1c26980. SRCTREE/kern/disk.c:389: Reading `/vdevice/v-s...@3016/d...@8100,1'... [snip] SRCTREE/kern/disk.c:389: Reading `/vdevice/v-s...@3016/d...@8100,1'... SRCTREE/disk/ieee1275/ofdisk.c:239: Reading handle 0x19ff180: sector 0x2c8, size 0x8, buf 0x1c26980. SRCTREE/kern/disk.c:389: Reading `/vdevice/v-s...@3016/d...@8100,1'... [snip] SRCTREE/kern/disk.c:389: Reading `/vdevice/v-s...@3016/d...@8100,1'... SRCTREE/disk/ieee1275/ofdisk.c:239: Reading
Re: powerpc/sparc problems
Bean wrote: On Sat, Oct 24, 2009 at 4:34 AM, rubisher rubis...@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: 00c3c25c %SRR1: 8000b002 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 001001f4 deadbeef fffc 04 0001 08 1000 030002001000 0003 7000 0c 2280 00c17100 00c18000 0009c4b0 10 00db8c20 00db8939 00c57d80 00c58060 14 18 00c13000 00c38000 00c14d40 00c16ec0 1c 00c2 00c3fdf0 00c11ea0 00c10fa8 Special Regs: %IV: 0300 %CR: 8480%XER: 2008 %DSISR: 0800 %SRR0: 00c3c25c %SRR1: 8000b002 %LR: 00c3c1f0%CTR: %DAR: 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 NameRef Count Dependencies linux 1 boot,elf elf 2 gzio gzio3 ls 1 normal,extcmd extcmd 2 sh 1 normal normal 4 boot boot6 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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
On Sun, Oct 25, 2009 at 11:22 PM, rubisher rubis...@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/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
On Sat, Oct 24, 2009 at 4:34 AM, rubisher rubis...@scarlet.be wrote:
Bean wrote:
On Thu, Oct 22, 2009 at 5:12 PM, rubisher rubis...@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 bean12...@gmail.com
Date: Wed Oct 21 01:11:27 2009 +0800
Minor bug fix for parameter handling.
commit 8a3390f0164c89e8ae73884672556a9b31cbd766
Author: Bean bean12...@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
Re: powerpc/sparc problems
Bean wrote:
On Thu, Oct 22, 2009 at 5:12 PM, rubisher rubis...@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 bean12...@gmail.com
Date: Wed Oct 21 01:11:27 2009 +0800
Minor bug fix for parameter handling.
commit 8a3390f0164c89e8ae73884672556a9b31cbd766
Author: Bean bean12...@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
Re: powerpc/sparc problems
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 bean12...@gmail.com Date: Wed Oct 21 01:11:27 2009 +0800 Minor bug fix for parameter handling. commit 8a3390f0164c89e8ae73884672556a9b31cbd766 Author: Bean bean12...@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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
On Thu, Oct 22, 2009 at 5:12 PM, rubisher rubis...@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 bean12...@gmail.com Date: Wed Oct 21 01:11:27 2009 +0800 Minor bug fix for parameter handling. commit 8a3390f0164c89e8ae73884672556a9b31cbd766 Author: Bean bean12...@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/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
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=grub2ver=1.97~beta4-1arch=powerpcstamp=1254771207file=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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
Bean wrote: On Mon, Oct 12, 2009 at 4:55 PM, Felix Zielcke fziel...@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. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
On Thu, Oct 22, 2009 at 12:03 AM, rubisher rubis...@scarlet.be wrote: Bean wrote: On Mon, Oct 12, 2009 at 4:55 PM, Felix Zielcke fziel...@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/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
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=grub2ver=1.97~beta4-1arch=powerpcstamp=1254771207file=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) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
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=grub2ver=1.97~beta4-1arch=powerpcstamp=1254771207file=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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
Pavel Roskin wrote: On Fri, 2009-10-16 at 05:44 -0700, David Miller wrote: From: Pavel Roskin pro...@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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
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. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
From: Pavel Roskin pro...@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. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
Quoting David Miller da...@davemloft.net: From: Pavel Roskin pro...@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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
On Fri, 2009-10-16 at 05:44 -0700, David Miller wrote: From: Pavel Roskin pro...@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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
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 00400144 /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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
On Mon, Oct 12, 2009 at 06:31:12PM +0800, Bean wrote: On Mon, Oct 12, 2009 at 6:14 PM, David Miller da...@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. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
powerpc/sparc problems
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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
From: Felix Zielcke fziel...@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. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
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 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); ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
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=grub2ver=1.97~beta4-1arch=powerpcstamp=1254771207file=log -- Felix Zielcke Proud Debian Maintainer and GNU GRUB developer ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
Am Montag, den 12.10.2009, 02:05 -0700 schrieb David Miller: From: Felix Zielcke fziel...@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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
David Miller wrote: From: Felix Zielcke fziel...@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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
On Mon, Oct 12, 2009 at 4:55 PM, Felix Zielcke fziel...@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/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
From: Vladimir 'phcoder' Serbinenko phco...@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. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
From: Bean bean12...@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. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
David Miller wrote: From: Bean bean12...@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 pro...@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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
From: Vladimir 'phcoder' Serbinenko phco...@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 pro...@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. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
On Mon, Oct 12, 2009 at 6:14 PM, David Miller da...@davemloft.net wrote: From: Bean bean12...@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/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
From: Bean bean12...@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. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
On Mon, Oct 12, 2009 at 7:07 PM, David Miller da...@davemloft.net wrote: From: Bean bean12...@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/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: powerpc/sparc problems
From: Vladimir 'phcoder' Serbinenko phco...@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. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
