Re: Cross-compilation check broken

2009-01-29 Thread Robert Millan
On Wed, Jan 28, 2009 at 09:14:34PM -0500, Pavel Roskin wrote:
 Hello, Robert!
 
 Your commit 1955 breaks my script for testing PowerPC.  That's the
 script:
 
 #!/bin/sh
 set -e
 CROSS_PATH=/home/proski/src/buildroot/build_powerpc/staging_dir/usr/bin
 PATH=$CROSS_PATH:$PATH
 ./configure --with-platform=ieee1275 --target=powerpc-linux
 make -j2
 ./grub-mkrescue --grub-mkimage=./grub-mkelfimage --pkglibdir=. grub.iso
 qemu-system-ppc -nographic -cdrom grub.iso -boot d
 
 I compile for target powerpc-linux and I have powerpc-linux-gcc in the
 PATH.  However, I'm using native tools.  I'm not interested in running
 tools in an emulator (actually, I have another script that does it).
 Therefore, build and host are the same, so TARGET_CC is set to gcc.
 
 The new check must be wrong.  TARGET_CC is used to build executables for
 the target system.  It should be found using the specified target even
 if the tools are compiled natively.
 
 Actually, the original check wasn't particularly good.  Maybe we could
 check if target_alias is defined?  Or maybe we could always check for
 TARGET_CC?

Hi Pavel,

This check looks really confusing.  I naively assumed it was checking if we're
cross-compiling like the comment said ;-)

But if it really meant to compare target with host, I think it should be:

  if test x$target_cpu != x$host_cpu; then

rather than what was before:

  if test x$target != x$host; then

Since $target_os has no real meaning.  Does that work for you?

-- 
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


Move BSD and multiboot boot helper out of the kernel to their respective modules

2009-01-29 Thread phcoder

Hello, I was looking through the code and have seen that bsd and
multiboot code uses helpers in the kernel. In this patch I propose to
move these function to their respective modules
Thanks
Vladimir 'phcoder' Serbinenko

Index: conf/i386-pc.rmk
===
--- conf/i386-pc.rmk	(revision 1962)
+++ conf/i386-pc.rmk	(working copy)
@@ -219,11 +219,13 @@
 
 # For _multiboot.mod.
 _multiboot_mod_SOURCES = loader/i386/pc/multiboot.c \
+			 loader/i386/multiboot.S \
  loader/i386/pc/multiboot2.c \
  loader/multiboot2.c \
  loader/multiboot_loader.c
 _multiboot_mod_CFLAGS = $(COMMON_CFLAGS)
 _multiboot_mod_LDFLAGS = $(COMMON_LDFLAGS)
+_multiboot_mod_ASFLAGS = $(COMMON_ASFLAGS)
 
 # For multiboot.mod.
 multiboot_mod_SOURCES = loader/multiboot_loader_normal.c 
@@ -282,10 +284,12 @@
 aout_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
 # For _bsd.mod
-_bsd_mod_SOURCES = loader/i386/bsd.c
+_bsd_mod_SOURCES = loader/i386/bsd.c loader/i386/bsd_helper.S
 _bsd_mod_CFLAGS = $(COMMON_CFLAGS)
 _bsd_mod_LDFLAGS = $(COMMON_LDFLAGS)
+_bsd_mod_ASFLAGS = $(COMMON_ASFLAGS)
 
+
 # For bsd.mod
 bsd_mod_SOURCES = loader/i386/bsd_normal.c
 bsd_mod_CFLAGS = $(COMMON_CFLAGS)
Index: conf/i386-coreboot.rmk
===
--- conf/i386-coreboot.rmk	(revision 1962)
+++ conf/i386-coreboot.rmk	(working copy)
@@ -139,10 +139,12 @@
 # For _multiboot.mod.
 _multiboot_mod_SOURCES = loader/i386/pc/multiboot.c \
  loader/i386/pc/multiboot2.c \
+			 loader/i386/multiboot.S \
  loader/multiboot2.c \
  loader/multiboot_loader.c
 _multiboot_mod_CFLAGS = $(COMMON_CFLAGS)
 _multiboot_mod_LDFLAGS = $(COMMON_LDFLAGS)
+_multiboot_mod_ASFLAGS = $(COMMON_ASFLAGS)
 
 # For multiboot.mod.
 multiboot_mod_SOURCES = loader/multiboot_loader_normal.c 
Index: conf/i386-ieee1275.rmk
===
--- conf/i386-ieee1275.rmk	(revision 1962)
+++ conf/i386-ieee1275.rmk	(working copy)
@@ -113,10 +113,12 @@
 
 # For _multiboot.mod.
 _multiboot_mod_SOURCES = loader/ieee1275/multiboot2.c \
+			 loader/i386/multiboot.S \
 			 loader/multiboot2.c \
 			 loader/multiboot_loader.c
 _multiboot_mod_CFLAGS = $(COMMON_CFLAGS)
 _multiboot_mod_LDFLAGS = $(COMMON_LDFLAGS)
+_multiboot_mod_ASFLAGS = $(COMMON_ASFLAGS)
 
 # For multiboot.mod.
 multiboot_mod_SOURCES = loader/multiboot_loader_normal.c 
Index: kern/i386/loader.S
===
--- kern/i386/loader.S	(revision 1962)
+++ kern/i386/loader.S	(working copy)
@@ -117,127 +117,3 @@
 linux_setup_seg:
 	.word	0
 	.code32
-
-
-/*
- * This starts the multiboot kernel.
- */
-
-VARIABLE(grub_multiboot_payload_size)
-	.long	0
-VARIABLE(grub_multiboot_payload_orig)
-	.long	0
-VARIABLE(grub_multiboot_payload_dest)
-	.long	0
-VARIABLE(grub_multiboot_payload_entry_offset)
-	.long	0
-
-/*
- * The relocators below understand the following parameters:
- * ecx:	Size of the block to be copied.
- * esi:	Where to copy from (always lowest address, even if we're relocating
- *  backwards).
- * edi:	Where to copy to (likewise).
- * edx:	Offset of the entry point (relative to the beginning of the block).
- */
-VARIABLE(grub_multiboot_forward_relocator)
-	/* Add entry offset.  */
-	addl	%edi, %edx
-
-	/* Forward copy.  */
-	cld
-	rep
-	movsb
-
-	jmp	*%edx
-VARIABLE(grub_multiboot_forward_relocator_end)
-
-VARIABLE(grub_multiboot_backward_relocator)
-	/* Add entry offset (before %edi is mangled).  */
-	addl	%edi, %edx
-
-	/* Backward movsb is implicitly off-by-one.  compensate that.  */
-	decl	%esi
-	decl	%edi
-
-	/* Backward copy.  */
-	std
-	addl	%ecx, %esi
-	addl	%ecx, %edi
-	rep
-	movsb
-
-	jmp	*%edx
-VARIABLE(grub_multiboot_backward_relocator_end)
-
-FUNCTION(grub_multiboot_real_boot)
-	/* Push the entry address on the stack.  */
-	pushl	%eax
-	/* Move the address of the multiboot information structure to ebx.  */
-	movl	%edx,%ebx
-
-	/* Unload all modules and stop the floppy driver.  */
-	call	EXT_C(grub_dl_unload_all)
-	call	EXT_C(grub_stop_floppy)
-
-	/* Interrupts should be disabled.  */
-	cli
-
-	/* Where do we copy what from.  */
-	movl	EXT_C(grub_multiboot_payload_size), %ecx
-	movl	EXT_C(grub_multiboot_payload_orig), %esi
-	movl	EXT_C(grub_multiboot_payload_dest), %edi
-	movl	EXT_C(grub_multiboot_payload_entry_offset), %edx
-
-	/* Move the magic value into eax.  */
-	movl	$MULTIBOOT_MAGIC2, %eax
-
-	/* Jump to the relocator.  */
-	popl	%ebp
-	jmp 	*%ebp
-	
-/*
- * This starts the multiboot 2 kernel.
- */
-
-FUNCTION(grub_multiboot2_real_boot)
-/* Push the entry address on the stack.  */
-pushl   %eax
-/* Move the address of the multiboot information structure to ebx.  */
-movl%edx,%ebx
-
-/* Unload all modules and stop the floppy driver.  */
-

Re: State of GRUB on PowerPC

2009-01-29 Thread Michel Dänzer
On Wed, 2009-01-28 at 21:57 -0500, Pavel Roskin wrote:
 On Tue, 2009-01-27 at 08:19 +0100, Michel Dänzer wrote:
  I was able to reproduce Jordi's findings on my PowerBook G4. (Well,
  except device.map seems to get generated correctly and the search
  command seems to work for me, maybe this is due to differences between
  our OF device trees or something like that)
  
  After some printf-style debugging over the weekend, the failure to load
  some modules indeed turns out to be an hfs.mod bug: the problem is that
  strncasecmp() doesn't match the HFS B-tree sort order, which in
  particular breaks lookup of files with an underscore in their name. The
  first attached patch fixes this using a lookup table from Linux
  fs/hfs/string.c.
 
 Actually, the return value of grub_strncasecmp() was incorrect until
 recently.  Maybe the current version would work for you?

Unfortunately not; I verified with a simple program that the glibc
strncasecmp() also has a different order between underscore and
characters. The HFS sort order seems quite peculiar.

 I'm not against your patch, but I'd like to understand how important it
 is for GRUB.

The failure to look up some files on HFS filesystems makes it hard for
most PowerPC Mac Linux users to switch from yaboot to GRUB.

 Please write a ChangeLog entry for the patch.

How about this:

2009-01-29  Michel Dänzer  mic...@daenzer.net

* fs/hfs.c (grub_hfs_cmp_catkeys): Use lookup table for HFS
B-tree sort order. Otherwise we fail to look up some files,
e.g. with an underscore in the name, so e.g. the _linux module  
can't be loaded from an HFS filesystem.


  The failure to auto-load some modules like search was also caused by
  this, the auto-loading process aborts after failing to load a module. It
  might be better to continue auto-loading other modules anyway.
 
 Patches are welcome.  With explanations, please.

Just tossing out an idea.


  BTW, I also need the second attached patch to be able to boot my
  self-built 32 bit kernels configured to support 2GB lowmem.
  elf-ehdr.ehdr32.e_entry ends up as 0x7000.
 
 Strange.  The original mask should ensure that elf-ehdr.ehdr32.e_entry
 is less than 0x4000.

Right, that's the problem. :) Apparently the kernel's early boot code
relies on it remaining unchanged.


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Cross-compilation check broken

2009-01-29 Thread Pavel Roskin
On Thu, 2009-01-29 at 14:07 +0100, Robert Millan wrote:

 This check looks really confusing.  I naively assumed it was checking if we're
 cross-compiling like the comment said ;-)

I agree, the comment is misleading.  We actually check for the second
set of tools there, which is used to build files for the target.  The
first set is used to build for the host, and it can be a cross-compiler
as well.

 But if it really meant to compare target with host, I think it should be:
 
   if test x$target_cpu != x$host_cpu; then
 
 rather than what was before:
 
   if test x$target != x$host; then
 
 Since $target_os has no real meaning.  Does that work for you?

I understand that you are trying to exorcise $target_os by all means.
By from the user standpoint, the second set of tools is needed if the
--target option was specified and its argument is different from the
one for the --host option.

I would also like to get rid of ac_tool_prefix.  I'll have a look.  I
assume we can always look for $target_alias-gcc without falling back to
$target_alias-cc and $target_alias-egcs.

-- 
Regards,
Pavel Roskin


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


The ponderings of a newbie

2009-01-29 Thread Jay Sullivan
Hi everyone I have a few questions about different things.

Just so everyone can understand me better, allow me to describe my relation
to this project.  I am an C and x86 ASM programmer.  I'm very interested in
contributing to GRUB2, and I've been trying to understand it for a while,
but there are certain things preventing me from it.  I'm not very
experienced with patches and multi-user projects, however, which is why I'm
having trouble contributing.

1) Mailing lists:

I'm wanting to avoid asking questions that have already been answered, and
I'd like to keep up on current issues with grub2, so I'd like to try to keep
the grub-devel mailing list sorted...but I'm clueless.
First of all, is it strange of me to ask, What email managers are everyone
using?  I'm more of a forum guy, so I find mailing lists hard to work with,
and I'm hoping someone can clue me in on an email application that handles
mailing lists properly.  For example, on a forum, you can clearly see which
messages were responses to which questions.  But I can see the benefit of a
mailing list, as everyone can use their own mail handlers... but I've tried
to research things like sendmail, and my my brain nearly exploded.  Is there
a simple solution?

2) Documentation:

I've noticed that from inside the grub2 shell, for almost all standard
commands, the help *-h* and usage *-u* switches are not verbose at all.
I'm wondering, is this because (A) there is a general consensus that we
should avoid verbose documentation until grub2 is past beta stages? Or is it
(B) no one has yet offered to write the documentation? Or perhaps it might
be (C) everyone except for me finds the usage of commands so obvious that no
one but me has needed to type help yet? (kidding...but seriously I'm lost
here).

3)  Bug? Not a bug?

I consider myself a very detail-oriented person, both with human languages
and programming languages, and I have noticed several small glitches that
some might not consider bugs, but nonetheless they are undocumented and I'm
sure other people are having the same issue I am. I have a
*strong*suspicion that some of these bugs have already been well
reviewed by the
rest of you guys, and I've missed the conversation.  Something I'd like to
dicuss in depth with someone who is knowledgeable on grub2 source code is
that of the grub2 shell input, and whitespace handling, and tab-completion.
I don't know where to look in the source for this stuff and I'm not sure
what has been tried and what has been agreed upon.  Regardless, I really
think there are a few simple issues, and perhaps they are not really as
simple as they seem.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: The ponderings of a newbie

2009-01-29 Thread Vesa Jääskeläinen
Jay Sullivan wrote:
 1) Mailing lists:
 
 I'm wanting to avoid asking questions that have already been answered, and
 I'd like to keep up on current issues with grub2, so I'd like to try to keep
 the grub-devel mailing list sorted...but I'm clueless.
 First of all, is it strange of me to ask, What email managers are everyone
 using?  I'm more of a forum guy, so I find mailing lists hard to work with,
 and I'm hoping someone can clue me in on an email application that handles
 mailing lists properly.  For example, on a forum, you can clearly see which
 messages were responses to which questions.  But I can see the benefit of a
 mailing list, as everyone can use their own mail handlers... but I've tried
 to research things like sendmail, and my my brain nearly exploded.  Is there
 a simple solution?

Thunderbird + Threaded view for folder

Automatically filter mailing lists to own folders


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: The ponderings of a newbie

2009-01-29 Thread n0ano
I'm old school:

fetchmail: to get the mail.

procmail: to separate lists into individula folders.

mutt: to read the mail, it uses threaded mode by default.

On Thu, Jan 29, 2009 at 11:43:57PM +0200, Vesa J??skel?inen wrote:
 Jay Sullivan wrote:
  1) Mailing lists:
  
  I'm wanting to avoid asking questions that have already been answered, and
  I'd like to keep up on current issues with grub2, so I'd like to try to keep
  the grub-devel mailing list sorted...but I'm clueless.
  First of all, is it strange of me to ask, What email managers are everyone
  using?  I'm more of a forum guy, so I find mailing lists hard to work with,
  and I'm hoping someone can clue me in on an email application that handles
  mailing lists properly.  For example, on a forum, you can clearly see which
  messages were responses to which questions.  But I can see the benefit of a
  mailing list, as everyone can use their own mail handlers... but I've tried
  to research things like sendmail, and my my brain nearly exploded.  Is there
  a simple solution?
 
 Thunderbird + Threaded view for folder
 
 Automatically filter mailing lists to own folders
 
 
 ___
 Grub-devel mailing list
 Grub-devel@gnu.org
 http://lists.gnu.org/mailman/listinfo/grub-devel

-- 
Don Dugger
Censeo Toto nos in Kansa esse decisse. - D. Gale
n0...@n0ano.com
Ph: 303/443-3786


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: The ponderings of a newbie

2009-01-29 Thread step21
google mail and a filter to label each mailing list seperately,
normally related messages are kept together in a conversation



On Thu, Jan 29, 2009 at 10:43 PM, Vesa Jääskeläinen ch...@nic.fi wrote:
 Jay Sullivan wrote:
 1) Mailing lists:

 I'm wanting to avoid asking questions that have already been answered, and
 I'd like to keep up on current issues with grub2, so I'd like to try to keep
 the grub-devel mailing list sorted...but I'm clueless.
 First of all, is it strange of me to ask, What email managers are everyone
 using?  I'm more of a forum guy, so I find mailing lists hard to work with,
 and I'm hoping someone can clue me in on an email application that handles
 mailing lists properly.  For example, on a forum, you can clearly see which
 messages were responses to which questions.  But I can see the benefit of a
 mailing list, as everyone can use their own mail handlers... but I've tried
 to research things like sendmail, and my my brain nearly exploded.  Is there
 a simple solution?

 Thunderbird + Threaded view for folder

 Automatically filter mailing lists to own folders


 ___
 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


Implementing commands from TODO list

2009-01-29 Thread Bandan
First thing's first; I finally realized while getting my daily dose of grub2 
that I had unintentionally tried to post my message in a wrong thread 
here :
http://lists.gnu.org/archive/html/grub-devel/2009-01/msg00157.html 

It was very careless on my part and I sincerely apologize for the noise 
(sorry phcoder and Vesa Jääskeläinen ! ).

Now to my point:

I was looking at the TODO list here http://grub.enbug.org/TodoList into 
the list of missing commands http://grub.enbug.org/CommandList. As I 
see that there is not much talk about  them on the list, I would like to 
track the missing commands and start adding them to Grub2. 
Personally, I would like to start with uppermem as I have already 
gone through the relevant code and it will be easier for me to start with 
it.

Any ideas/suggestions would be greatly appreciated.

Thanks,
Bandan
 
-- 
BSD


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel


Re: Implementing commands from TODO list

2009-01-29 Thread phcoder

Bandan wrote:

(sorry phcoder and Vesa Jääskeläinen ! ).

NP
Personally, I would like to start with uppermem as I have already 
gone through the relevant code and it will be easier for me to start with 
it.

Uppermem is i386-bound. I propose more general format:
meminfo [-l] [-s VAR]
Which outputs total amount of memory.
If launched with -s VAR this value is stored to variable
If launched with -v it outputs complete memory map

Thank
Vladimir 'phcoder' Serbinenko


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel