G5 powerpc64 undefined reference to `grub_machine_mmap_iterate'
After Revision 1924 Harmonize ieee1275's grub_available_iterate() with the generic grub_machine_mmap_iterate() Attempting to make Rev 1928, configuration ieee1275 on G5 powerpc64 I am stuck with this error: kernel_elf-kern_ieee1275_init.o: In function `grub_claim_heap': /home/pxw/src/grub2/build/../kern/ieee1275/init.c:182: undefined reference to `grub_machine_mmap_iterate' kernel_elf-symlist.o:(.data+0x38c): undefined reference to `grub_machine_mmap_iterate' collect2: ld returned 1 exit status make: *** [kernel.elf] Error 1 I cant find it, would appreciate help. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: G5 powerpc64 undefined reference to `grub_machine_mmap_iterate'
I have already sent a patch to correct this. look at the email with subject [PATCH] Compilation PowerPC64. It should work for you. On Sat, 2008-11-29 at 00:12 +1100, peter cros wrote: After Revision 1924 Harmonize ieee1275's grub_available_iterate() with the generic grub_machine_mmap_iterate() Attempting to make Rev 1928, configuration ieee1275 on G5 powerpc64 I am stuck with this error: kernel_elf-kern_ieee1275_init.o: In function `grub_claim_heap': /home/pxw/src/grub2/build/../kern/ieee1275/init.c:182: undefined reference to `grub_machine_mmap_iterate' kernel_elf-symlist.o:(.data+0x38c): undefined reference to `grub_machine_mmap_iterate' collect2: ld returned 1 exit status make: *** [kernel.elf] Error 1 I cant find it, would appreciate help. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Best Regards, Manoel Abranches [EMAIL PROTECTED] IBM Linux Technology Center Brazil ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
ld option --build-id=none
In the file conf/powerpc-ieee1275.rmk I need in newer ld versions to have: kernel_elf_LDFLAGS = $(COMMON_LDFLAGS) -static-libgcc -lgcc \ -Wl,-N,-S,-Ttext,0x20,-Bstatic,--build-id=none and in older versions: kernel_elf_LDFLAGS = $(COMMON_LDFLAGS) -static-libgcc -lgcc \ -Wl,-N,-S,-Ttext,0x20,-Bstatic Should I move it from conf/powerpc-ieee1275.rmk to the configure script? -- Best Regards, Manoel Abranches [EMAIL PROTECTED] IBM Linux Technology Center Brazil ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] (ata.mod) avoid passing grub_errno to upper layer
On Tue, Nov 25, 2008 at 10:17:17PM +0100, Yoshinori K. Okuji wrote: On Saturday 22 November 2008 16:35:09 Robert Millan wrote: When an error is detected by ata.mod during drive scan, it will pass it to the upper layer. This results in GRUB aborting when trying to enter normal mode, even if the error is not critical (e.g. affects a drive not used during boot). There are a number of places in ata.mod where these errors could be handled, so I'm not sure if my proposed change would be the best approach. Some comment would be appreciated. This is one way, but I think the upper layer should be more robust against errors raised from modules. For example, we can unload a module, and clear GRUB_ERRNO, if the init function in this module return an error. But if the error is specific to a device unit, unloading the module would result in all units of this device class being disabled, which is most likely not what we want. -- 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: grub.elf? As in How do I create that?
On Sat, Nov 22, 2008 at 09:33:11PM -0500, Gregg Levine wrote: On Sat, Nov 22, 2008 at 2:58 PM, Robert Millan [EMAIL PROTECTED] wrote: On Wed, Nov 12, 2008 at 08:05:24PM -0500, Gregg Levine wrote: Hello! You did reply on the coreboot list, however I am still working out how to build the grub.elf kernel. First I need to know how to translate the kernel.img file into kernel.elf since there is a kernel.img file but not a kernel.elf one. Did you pass --with-platform=coreboot to configure? -- Robert Millan Hello! And that did work. Is this selection part of a wiki page some place? If not it should be. It is. See http://grub.enbug.org/CoreBoot -- 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: [PATCH] Compilation PowerPC64
On Mon, Nov 24, 2008 at 04:30:45PM -0500, Pavel Roskin wrote: On Mon, 2008-11-24 at 17:58 -0200, Manoel wrote: This patch corrects compilation in PowerPC64 due to some recent changes. The compilation problems exist even when compiling for 32-bit PowerPC. However, I'm getting errors in qemu with your patch: stack: 5bfff80 malloc_base: 0 0x0580 0x0600 ERROR: OF_property_copy cannot get property 'CodeGen-copyright' for openprom ERROR: OF_property_copy cannot get property 'architecture' for device-tree Warning: attempt to claim over our own code! Welcome to GRUB! out of memory Aborted. Press any key to exit Not sure if that's related, but I suggest you try a pre-r1924 snapshot and see if that works. -- 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: [PATCH] Compilation PowerPC64
On Mon, Nov 24, 2008 at 05:58:23PM -0200, Manoel wrote: This patch corrects compilation in PowerPC64 due to some recent changes. Thanks. Committed with some adjustments. Btw, please include a ChangeLog entry next time! -- 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: [PATCH] grub-install on coreboot
Committed (after adjusting indentation)
On Sat, Nov 22, 2008 at 04:53:14PM +0100, Robert Millan wrote:
Hi,
This patch implements grub-install on coreboot. Since there's no pre-defined
boot protocol on this platform, we simply generate a usable Multiboot image
and dump it to /boot. User can afterwards load it to flash to make the board
boot using this disk, or load it from elsewhere (even from a BIOS rescue
disk).
I hope it's not too intrusive to reuse i386-pc's grub-install; I think it's
much better than duplicating the whole script.
Note: indentation changes intentionally ommitted to improve readability.
--
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.
2008-11-22 Robert Millan [EMAIL PROTECTED]
* conf/i386-coreboot.rmk (sbin_SCRIPTS): Add `grub-install'.
(grub_install_SOURCES): New variable.
* util/i386/pc/grub-install.in: Add a few condition checks to make it
usable on coreboot.
Index: conf/i386-coreboot.rmk
===
--- conf/i386-coreboot.rmk(revision 1926)
+++ conf/i386-coreboot.rmk(working copy)
@@ -90,6 +90,9 @@ grub_emu_SOURCES = commands/boot.c comma
grub_emu_LDFLAGS = $(LIBCURSES)
+sbin_SCRIPTS += grub-install
+grub_install_SOURCES = util/i386/pc/grub-install.in
+
# Modules.
pkglib_MODULES = _linux.mod linux.mod normal.mod \
_multiboot.mod multiboot.mod aout.mod \
Index: util/i386/pc/grub-install.in
===
--- util/i386/pc/grub-install.in (revision 1926)
+++ util/i386/pc/grub-install.in (working copy)
@@ -32,7 +32,11 @@ [EMAIL PROTECTED]@
pkglibdir=${libdir}/`echo ${PACKAGE_TARNAME}/${target_cpu}-${platform} | sed
${transform}`
grub_setup=${sbindir}/`echo grub-setup | sed ${transform}`
+if [ ${target_cpu}-${platform} = i386-pc ] ; then
grub_mkimage=${bindir}/`echo grub-mkimage | sed ${transform}`
+else
+grub_mkimage=${bindir}/`echo grub-mkelfimage | sed ${transform}`
+fi
grub_mkdevicemap=${sbindir}/`echo grub-mkdevicemap | sed ${transform}`
grub_probe=${sbindir}/`echo grub-probe | sed ${transform}`
rootdir=
@@ -152,6 +156,7 @@ device_map=${grubdir}/device.map
grub_probe=${grub_probe} --device-map=${device_map}
+if [ ${target_cpu}-${platform} = i386-pc ] ; then
# Check if GRUB is installed.
set $grub_setup dummy
if test -f $1; then
@@ -160,6 +165,7 @@ else
echo $1: Not found. 12
exit 1
fi
+fi
set $grub_mkimage dummy
if test -f $1; then
@@ -210,9 +216,14 @@ for file in ${grubdir}/*.mod ${grubdir}/
rm -f $file || exit 1
fi
done
-for file in ${pkglibdir}/*.mod ${pkglibdir}/*.lst ${pkglibdir}/*.img; do
+for file in ${pkglibdir}/*.mod ${pkglibdir}/*.lst; do
+cp -f $file ${grubdir} || exit 1
+done
+if [ ${target_cpu}-${platform} = i386-pc ] ; then
+for file in ${pkglibdir}/*.img; do
cp -f $file ${grubdir} || exit 1
done
+fi
# Write device to a variable so we don't have to traverse /dev every time.
grub_device=`$grub_probe --target=device ${grubdir}`
@@ -234,7 +245,12 @@ partmap_module=`$grub_probe --target=par
devabstraction_module=`$grub_probe --target=abstraction --device
${grub_device}`
# The order in this list is critical. Be careful when modifying it.
-modules=$modules $fs_module $partmap_module biosdisk $devabstraction_module
+if [ ${target_cpu}-${platform} = i386-pc ] ; then
+ modules=$modules biosdisk
+else
+ modules=$modules ata
+fi
+modules=$modules $fs_module $partmap_module $devabstraction_module
prefix_drive=
if [ x${devabstraction_module} = x ] ; then
@@ -248,7 +264,16 @@ if [ x${devabstraction_module} = x ]
# Strip partition number
install_drive=`echo ${install_drive} | sed -e s/,[0-9]*//g`
grub_drive=`echo ${grub_drive} | sed -e s/,[0-9]*//g`
-if [ x${grub_drive} != x${install_drive} ] ; then
+if [ ${target_cpu}-${platform} != i386-pc ] ; then
+# generic method (used on coreboot)
+uuid=`$grub_probe --target=fs_uuid --device ${grub_device}`
+if [ x${uuid} = x ] ; then
+ echo UUID needed on this platform, but the filesystem containing
${grubdir} does not support UUIDs. 12
+ exit 1
+fi
+prefix_drive=(UUID=${uuid})
+modules=$modules fs_uuid
+elif [ x${grub_drive} != x${install_drive} ] ; then
uuid=`$grub_probe --target=fs_uuid --device ${grub_device}`
if [ x${uuid} = x ] ; then
echo You attempted a cross-disk install, but the filesystem
containing ${grubdir} does not support UUIDs. 12
@@ -266,12 +291,20 @@ if [ x${relative_grubdir} = x ] ; th
relative_grubdir=/
fi
+if [
Re: ld option --build-id=none
But it is only passed in modules compilation. I need it when creating kernel.elf as well. On Fri, 2008-11-28 at 20:59 +0100, Robert Millan wrote: On Fri, Nov 28, 2008 at 01:21:43PM -0200, Manoel Rebelo Abranches wrote: In the file conf/powerpc-ieee1275.rmk I need in newer ld versions to have: kernel_elf_LDFLAGS = $(COMMON_LDFLAGS) -static-libgcc -lgcc \ -Wl,-N,-S,-Ttext,0x20,-Bstatic,--build-id=none and in older versions: kernel_elf_LDFLAGS = $(COMMON_LDFLAGS) -static-libgcc -lgcc \ -Wl,-N,-S,-Ttext,0x20,-Bstatic Should I move it from conf/powerpc-ieee1275.rmk to the configure script? I thought it was there already (or something similar): aclocal.m4:[AC_MSG_CHECKING([whether linker accepts --build-id=none]) -- Best Regards, Manoel Abranches [EMAIL PROTECTED] IBM Linux Technology Center Brazil ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Corrections to affs and sfs
On Sat, Nov 22, 2008 at 08:55:19PM +0100, Krzysztof Smiechowicz wrote:
Hello,
I would like to submit the following patch:
* fs/affs.c: Return failure when directory iteration failed.
* fs/sfs.c: Return failure when directory iteration failed. Correct
order in which btree nodes are read.
These changes are needed to boot AROS Research Operating System from SFS
/ FFS.
Hi,
Index: fs/affs.c
===
--- fs/affs.c (revision 1919)
+++ fs/affs.c (working copy)
@@ -381,7 +381,7 @@
fail:
grub_free (node);
grub_free (hashtable);
- return 1;
+ return 0;
}
I checked in this hunk (and the equivalent sfs.c one)
Index: fs/sfs.c
===
--- fs/sfs.c (revision 1919)
+++ fs/sfs.c (working copy)
@@ -172,7 +172,8 @@
return grub_errno;
}
- for (i = 0; i grub_be_to_cpu16 (tree-nodes); i++)
+ grub_uint16_t nodescount = grub_be_to_cpu16(tree-nodes);
+ for (i = nodescount - 1; i = 0; i--)
nodescount is only used once; why adding a variable?
/* Follow the tree down to the leaf level. */
- if ((grub_be_to_cpu32 (EXTNODE(tree, i)-key) = block)
+ if ((grub_be_to_cpu32 (EXTNODE(tree, i)-key) = block)
!tree-leaf)
{
- next = grub_be_to_cpu32 (EXTNODE (tree, i - 1)-data);
- break;
- }
-
- /* In case the last node is reached just use that one, it is
- the right match. */
- if (i + 1 == grub_be_to_cpu16 (tree-nodes) !tree-leaf)
- {
next = grub_be_to_cpu32 (EXTNODE (tree, i)-data);
break;
}
I'm not familiar with our SFS code. Marco, if you have a minute could you
review this part?
--
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: ld option --build-id=none
On Fri, Nov 28, 2008 at 06:11:12PM -0200, Manoel Rebelo Abranches wrote: But it is only passed in modules compilation. I need it when creating kernel.elf as well. I assume we want this for every *_elf target? Then we shouldn't be restricting it to modules (perhaps this comes from the assumption that only modules use ELF, which is true on i386-pc) -- 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: ld option --build-id=none
Its not necessary when creating the .o object files, only when linking then to create the final kern.elf. That is done changing the variable kernel_elf_LDFLAGS in conf/powerpc-ieee1275.rmk. but I dont know how to use the grub_cv_prog_ld_build_id_none variable in aclocal.m4 to change kernelelf_LDFLAGS in the conf/powerpc-ieee1275.rm file. Thanks in advance for the help. On Fri, 2008-11-28 at 21:17 +0100, Robert Millan wrote: On Fri, Nov 28, 2008 at 06:11:12PM -0200, Manoel Rebelo Abranches wrote: But it is only passed in modules compilation. I need it when creating kernel.elf as well. I assume we want this for every *_elf target? Then we shouldn't be restricting it to modules (perhaps this comes from the assumption that only modules use ELF, which is true on i386-pc) -- Best Regards, Manoel Abranches [EMAIL PROTECTED] IBM Linux Technology Center Brazil ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] Multi-terminal support (Re: [PATCH] terminal split)
On Tue, Nov 25, 2008 at 10:23:52PM +0100, Yoshinori K. Okuji wrote: I've been thinking... what if we make this generic? I.e. with an event loop, then terminals can register their poll functions to it, and write their stuff to a shared resource the rest of GRUB can read from. For inputs, this is trivial for me. But, for outputs, not simple. For example, although we don't support yet in GRUB 2, if we have a dumb terminal, the menu interface must be very different from others. Aside from the problem with output ones, what to you think of the event loop idea? It can be useful exploit the parellelism in hardware initialisations. Currently GRUB can do silly things like: - wait for keyboard controller in grub_keyboard_controller_read() and in grub_keyboard_controller_write() - move on - wait for ATA disk in grub_atapi_read() - move on - wait for _user_ to stare at the menu and pick an option - move on which could be avoided this way (instead of waiting, each function would register a hook that will be repeatedly run untill it returns non-zero). -- 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: ld option --build-id=none
On Fri, Nov 28, 2008 at 06:30:22PM -0200, Manoel Rebelo Abranches wrote: Its not necessary when creating the .o object files, only when linking then to create the final kern.elf. That is done changing the variable kernel_elf_LDFLAGS in conf/powerpc-ieee1275.rmk. but I dont know how to use the grub_cv_prog_ld_build_id_none variable in aclocal.m4 to change kernelelf_LDFLAGS in the conf/powerpc-ieee1275.rm file. Look in genmk.rb. The class Image stanza adds a -R .note.gnu.build-id to objcopy, which gets rid of the build-id for *.img files on i386-pc. For ELF images, I think you need something similar in class Program. -- 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
