[PATCH]: grub: Add revamped kernel startup code for sparc64.

[David Miller]

I've commited these changes.

2009-04-12 David S. Miller 

* kern/sparc64/ieee1275/init.c: Delete, replace with...
* kern/sparc64/ieee1275/crt0.S: assembler implementation.
* include/grub/sparc64/ieee1275/kernel.h: Declare grub_prefix[].
(GRUB_MOD_ALIGN, GRUB_MOD_GAP, GRUB_KERNEL_MACHINE_TOTAL_MODULE_SIZE,
GRUB_KERNEL_MACHINE_KERNEL_IMAGE_SIZE,
GRUB_KERNEL_MACHINE_COMPRESSED_SIZE, GRUB_KERNEL_MACHINE_PREFIX,
GRUB_KERNEL_MACHINE_DATA_END): Define.
(grub_kernel_image_size, grub_total_module_size): Declare.
---
 include/grub/sparc64/ieee1275/kernel.h |   38 +-
 kern/sparc64/ieee1275/crt0.S   |   77 ++
 kern/sparc64/ieee1275/init.c   |  237 
 3 files changed, 112 insertions(+), 240 deletions(-)
 create mode 100644 kern/sparc64/ieee1275/crt0.S
 delete mode 100644 kern/sparc64/ieee1275/init.c

diff --git a/include/grub/sparc64/ieee1275/kernel.h 
b/include/grub/sparc64/ieee1275/kernel.h
index 0b6bce2..03a6314 100644
--- a/include/grub/sparc64/ieee1275/kernel.h
+++ b/include/grub/sparc64/ieee1275/kernel.h
@@ -1,6 +1,6 @@
 /*
  *  GRUB  --  GRand Unified Bootloader
- *  Copyright (C) 2005,2007  Free Software Foundation, Inc.
+ *  Copyright (C) 2005,2007,2009  Free Software Foundation, Inc.
  *
  *  GRUB is free software: you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
@@ -19,12 +19,44 @@
 #ifndef GRUB_KERNEL_MACHINE_HEADER
 #define GRUB_KERNEL_MACHINE_HEADER 1
 
+#define GRUB_MOD_ALIGN 0x2000
+
+/* Non-zero value is only needed for PowerMacs.  */
+#define GRUB_MOD_GAP 0x0
+
+/* The offset of GRUB_TOTAL_MODULE_SIZE.  */
+#define GRUB_KERNEL_MACHINE_TOTAL_MODULE_SIZE  0x8
+
+/* The offset of GRUB_KERNEL_IMAGE_SIZE.  */
+#define GRUB_KERNEL_MACHINE_KERNEL_IMAGE_SIZE  0xc
+
+/* The offset of GRUB_COMPRESSED_SIZE.  */
+#define GRUB_KERNEL_MACHINE_COMPRESSED_SIZE0x10
+
+/* The offset of GRUB_PREFIX.  */
+#define GRUB_KERNEL_MACHINE_PREFIX 0x14
+
+/* End of the data section. */
+#define GRUB_KERNEL_MACHINE_DATA_END   0x114
+
+#ifndef ASM_FILE
+
 #include 
+#include 
+
+/* The size of kernel image.  */
+extern grub_int32_t grub_kernel_image_size;
+
+/* The total size of module images following the kernel.  */
+extern grub_int32_t grub_total_module_size;
+
+/* The prefix which points to the directory where GRUB modules and its
+   configuration file are located.  */
+extern char grub_prefix[];
 
 void EXPORT_FUNC (grub_reboot) (void);
 void EXPORT_FUNC (grub_halt) (void);
 
-/* Where grub-mkimage places the core modules in memory.  */
-#define GRUB_IEEE1275_MODULE_BASE 0x0030
+#endif /* ! ASM_FILE */
 
 #endif /* ! GRUB_KERNEL_MACHINE_HEADER */
diff --git a/kern/sparc64/ieee1275/crt0.S b/kern/sparc64/ieee1275/crt0.S
new file mode 100644
index 000..4e67cbc
--- /dev/null
+++ b/kern/sparc64/ieee1275/crt0.S
@@ -0,0 +1,77 @@
+/* crt0.S - Startup code for the Sparc64.  */
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2009  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see .
+ */
+#include 
+#include 
+
+   .text
+   .align  4
+   .globl  _start
+_start:
+   ba  codestart
+nop
+
+   . = EXT_C(_start) + GRUB_KERNEL_MACHINE_TOTAL_MODULE_SIZE
+
+VARIABLE(grub_total_module_size)
+   .word   0
+VARIABLE(grub_kernel_image_size)
+   .word   0
+VARIABLE(grub_compressed_size)
+   .word   0
+VARIABLE(grub_prefix)
+   /* to be filled by grub-mkimage */
+
+   /*
+*  Leave some breathing room for the prefix.
+*/
+
+   . = EXT_C(_start) + GRUB_KERNEL_MACHINE_DATA_END
+
+codestart:
+   /* Copy the modules past the end of the kernel image.
+* They are currently sitting in the BSS.
+*/
+   sethi   %hi(__bss_start), %o2
+   or  %o2, %lo(__bss_start), %o2
+   sethi   %hi(_end), %o3
+   or  %o3, %lo(_end), %o3
+   sethi   %hi(grub_total_module_size), %o4
+   lduw[%o4 + %lo(grub_total_module_size)], %o4
+1: lduw[%o2], %o5
+   stw %o5, [%o3]
+   subcc   %o4, 4, %o4
+   add %o2, 4, %o2
+   bne,pt  %icc, 1b
+add%o3, 4, %o3
+
+   /* Now it's safe to clear out the BSS.  */
+   sethi   %hi(__bss_start), %o2
+   or  %o2, 

grub: Add ieee1275 interfaces for phys and virt memory allocation on sparc64.

[David Miller]

This adds the ieee1275 interfaces sparc64's openboot has for
allocating physical memory, creating mappings, etc.

We can't reuse any of the existing similar calls used by powerpc since
these use two cells for passing physical addresses (even though only
one of those cell slots is used, this is legacy carry over from 32-bit
sparc times).

Committed.

2009-04-13  David S. Miller  

* kern/sparc64/ieee1275/ieee1275.c: New file.
* include/grub/sparc64/ieee1275/ieee1275.h (IEEE1275_MAP_WRITE,
IEEE1275_MAP_READ, IEEE1275_MAP_EXEC, IEEE1275_MAP_LOCKED,
IEEE1275_MAP_CACHED, IEEE1275_MAP_SE, IEEE1275_MAP_GLOBAL,
IEEE1275_MAP_IE, IEEE1275_MAP_DEFAULT): Define.
(grub_ieee1275_map_physical, grub_ieee1275_claim_vaddr,
grub_ieee1275_alloc_physmem): Declare new exported functions.
---
 include/grub/sparc64/ieee1275/ieee1275.h |   22 +
 kern/sparc64/ieee1275/ieee1275.c |  124 ++
 2 files changed, 146 insertions(+), 0 deletions(-)
 create mode 100644 kern/sparc64/ieee1275/ieee1275.c

diff --git a/include/grub/sparc64/ieee1275/ieee1275.h 
b/include/grub/sparc64/ieee1275/ieee1275.h
index 1ef95f9..7626e93 100644
--- a/include/grub/sparc64/ieee1275/ieee1275.h
+++ b/include/grub/sparc64/ieee1275/ieee1275.h
@@ -24,4 +24,26 @@
 
 typedef grub_uint64_t grub_ieee1275_cell_t;
 
+/* Encoding of 'mode' argument to grub_ieee1275_map_physical() */
+#define IEEE1275_MAP_WRITE 0x0001 /* Writable */
+#define IEEE1275_MAP_READ  0x0002 /* Readable */
+#define IEEE1275_MAP_EXEC  0x0004 /* Executable */
+#define IEEE1275_MAP_LOCKED0x0010 /* Locked in TLB */
+#define IEEE1275_MAP_CACHED0x0020 /* Cacheable */
+#define IEEE1275_MAP_SE0x0040 /* Side-effects */
+#define IEEE1275_MAP_GLOBAL0x0080 /* Global */
+#define IEEE1275_MAP_IE0x0100 /* Invert Endianness */
+#define IEEE1275_MAP_DEFAULT   (IEEE1275_MAP_WRITE | IEEE1275_MAP_READ | \
+IEEE1275_MAP_EXEC | IEEE1275_MAP_CACHED)
+
+extern int EXPORT_FUNC(grub_ieee1275_map_physical) (grub_addr_t paddr,
+   grub_addr_t vaddr,
+   grub_size_t size,
+   grub_uint32_t mode);
+extern int EXPORT_FUNC(grub_ieee1275_claim_vaddr) (grub_addr_t vaddr,
+  grub_size_t size);
+extern int EXPORT_FUNC(grub_ieee1275_alloc_physmem) (grub_addr_t *paddr,
+grub_size_t size,
+grub_uint32_t align);
+
 #endif /* ! GRUB_IEEE1275_MACHINE_HEADER */
diff --git a/kern/sparc64/ieee1275/ieee1275.c b/kern/sparc64/ieee1275/ieee1275.c
new file mode 100644
index 000..438a171
--- /dev/null
+++ b/kern/sparc64/ieee1275/ieee1275.c
@@ -0,0 +1,124 @@
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2009  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see .
+ */
+
+#include 
+#include 
+
+/* Sun specific ieee1275 interfaces used by GRUB.  */
+
+int
+grub_ieee1275_map_physical (grub_addr_t paddr, grub_addr_t vaddr,
+   grub_size_t size, grub_uint32_t mode)
+{
+  struct map_physical_args
+  {
+struct grub_ieee1275_common_hdr common;
+grub_ieee1275_cell_t method;
+grub_ieee1275_cell_t ihandle;
+grub_ieee1275_cell_t mode;
+grub_ieee1275_cell_t size;
+grub_ieee1275_cell_t virt;
+grub_ieee1275_cell_t phys_high;
+grub_ieee1275_cell_t phys_low;
+grub_ieee1275_cell_t catch_result;
+  }
+  args;
+
+  INIT_IEEE1275_COMMON (&args.common, "call-method", 7, 1);
+  args.method = (grub_ieee1275_cell_t) "map";
+  args.ihandle = grub_ieee1275_mmu;
+  args.mode = mode;
+  args.size = size;
+  args.virt = vaddr;
+  args.phys_high = 0;
+  args.phys_low = paddr;
+  args.catch_result = (grub_ieee1275_cell_t) -1;
+
+  if (IEEE1275_CALL_ENTRY_FN (&args) == -1)
+return -1;
+  return args.catch_result;
+}
+
+int
+grub_ieee1275_claim_vaddr (grub_addr_t vaddr, grub_size_t size)
+{
+  struct claim_vaddr_args
+  {
+struct grub_ieee1275_common_hdr common;
+grub_ieee1275_cell_t method;
+grub_ieee1275_cell_t ihandle;
+grub_ieee1275_cell_t align;
+grub_ieee1275_cell_t size;
+grub_ieee12

[PATCH]: grub: Add sparc64 Linux kernel loader support.

[David Miller]

This adds the sparc64 loader for Linux kernels.

Committed.

2009-04-13 David S. Miller 

* include/grub/sparc64/ieee1275/loader.h: New file.
* include/grub/sparc64/ieee1275/memory.h: Likewise.
* include/grub/sparc64/kernel.h: Likewise.
* loader/sparc64/ieee1275/linux.c: Likewise.
---
 include/grub/sparc64/ieee1275/loader.h |   27 ++
 include/grub/sparc64/ieee1275/memory.h |   24 ++
 include/grub/sparc64/kernel.h  |   30 ++
 loader/sparc64/ieee1275/linux.c|  514 
 4 files changed, 595 insertions(+), 0 deletions(-)
 create mode 100644 include/grub/sparc64/ieee1275/loader.h
 create mode 100644 include/grub/sparc64/ieee1275/memory.h
 create mode 100644 include/grub/sparc64/kernel.h
 create mode 100644 loader/sparc64/ieee1275/linux.c

diff --git a/include/grub/sparc64/ieee1275/loader.h 
b/include/grub/sparc64/ieee1275/loader.h
new file mode 100644
index 000..12bb2a6
--- /dev/null
+++ b/include/grub/sparc64/ieee1275/loader.h
@@ -0,0 +1,27 @@
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2009  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see .
+ */
+
+#ifndef GRUB_LOADER_MACHINE_HEADER
+#define GRUB_LOADER_MACHINE_HEADER 1
+
+/* The symbol shared between the normal mode and rescue mode
+   loader.  */
+void grub_rescue_cmd_linux (int argc, char *argv[]);
+void grub_rescue_cmd_initrd (int argc, char *argv[]);
+
+#endif /* ! GRUB_LOADER_MACHINE_HEADER */
diff --git a/include/grub/sparc64/ieee1275/memory.h 
b/include/grub/sparc64/ieee1275/memory.h
new file mode 100644
index 000..c997f66
--- /dev/null
+++ b/include/grub/sparc64/ieee1275/memory.h
@@ -0,0 +1,24 @@
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2009 Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see .
+ */
+
+#ifndef GRUB_MEMORY_MACHINE_HEADER
+#define GRUB_MEMORY_MACHINE_HEADER 1
+
+#define GRUB_MACHINE_MEMORY_AVAILABLE  1
+
+#endif
diff --git a/include/grub/sparc64/kernel.h b/include/grub/sparc64/kernel.h
new file mode 100644
index 000..9f404b0
--- /dev/null
+++ b/include/grub/sparc64/kernel.h
@@ -0,0 +1,30 @@
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2005,2006,2007,2008  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see .
+ */
+
+#ifndef GRUB_KERNEL_CPU_HEADER
+#define GRUB_KERNEL_CPU_HEADER 1
+
+#define GRUB_MOD_ALIGN 0x2000
+
+/* Non-zero value is only needed for PowerMacs.  */
+#define GRUB_MOD_GAP 0x0
+
+#define GRUB_KERNEL_CPU_PREFIX 0x2
+#define GRUB_KERNEL_CPU_DATA_END   0x42
+
+#endif
diff --git a/loader/sparc64/ieee1275/linux.c b/loader/sparc64/ieee1275/linux.c
new file mode 100644
index 000..4912b97
--- /dev/null
+++ b/loader/sparc64/ieee1275/linux.c
@@ -0,0 +1,514 @@
+/* linux.c - boot Linux */
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2003, 2004, 2005, 2007, 2009  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or

Re: [PATCH]: grub: Add Sun partition support to grub-probe and grub-fstest.

[Chip Panarchy]

Hello

When you mention 'Sun Partition' what file-system are you specifying?

ZFS?
UFS?

On Mon, Apr 13, 2009 at 4:53 PM, David Miller  wrote:
>
> Should be self-explanatory, these tools will be used on sparc64 just
> like they are on i386-pc
>
> 2009-04-12  David S. Miller  
>
>        * conf/common.rmk (grub_probe_SOURCES): Add Sun partition module.
>        (grub_fstest_SOURCES): Likewise.
> ---
>  conf/common.rmk |    5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/conf/common.rmk b/conf/common.rmk
> index b0a78b0..185779c 100644
> --- a/conf/common.rmk
> +++ b/conf/common.rmk
> @@ -19,7 +19,7 @@ grub_probe_SOURCES = util/grub-probe.c        \
>        fs/ntfs.c fs/ntfscomp.c fs/reiserfs.c fs/sfs.c          \
>        fs/ufs.c fs/xfs.c fs/afs.c fs/tar.c                     \
>        \
> -       partmap/pc.c partmap/apple.c partmap/gpt.c              \
> +       partmap/pc.c partmap/apple.c partmap/sun.c partmap/gpt.c\
>        kern/fs.c kern/env.c fs/fshelp.c                        \
>        disk/raid.c disk/mdraid_linux.c disk/lvm.c grub_probe_init.c
>
> @@ -40,7 +40,8 @@ grub_fstest_SOURCES = util/grub-fstest.c util/hostfs.c 
> util/misc.c    \
>        fs/ntfs.c fs/ntfscomp.c fs/reiserfs.c fs/sfs.c                  \
>        fs/ufs.c fs/xfs.c fs/afs.c fs/tar.c                             \
>        \
> -       kern/partition.c partmap/pc.c partmap/apple.c partmap/gpt.c     \
> +       kern/partition.c partmap/pc.c partmap/apple.c partmap/sun.c     \
> +       partmap/gpt.c                                                   \
>        kern/fs.c kern/env.c fs/fshelp.c disk/raid.c                    \
>        disk/raid5_recover.c disk/raid6_recover.c                       \
>        disk/mdraid_linux.c disk/dmraid_nvidia.c disk/lvm.c             \
> --
> 1.6.2.3
>
>
>
> ___
> 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: [PATCH]: grub: Add Sun partition support to grub-probe and grub-fstest.

[Felix Zielcke]

Am Montag, den 13.04.2009, 17:40 +1000 schrieb Chip Panarchy:
> Hello
> 
> When you mention 'Sun Partition' what file-system are you specifying?
> 
> ZFS?
> UFS?
> 

He surely meant Sun partition table format and not a filesystem. Grub2
doestn't support ZFS
Sun seems to have it's own partition table format just like pc (or
msdos) /gpt/apple/amiga/acorn which grub2 supports.
-- 
Felix Zielcke



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

Re: [PATCH]: grub: Add Sun partition support to grub-probe and grub-fstest.

[David Miller]

From: Chip Panarchy 
Date: Mon, 13 Apr 2009 17:40:22 +1000

> Hello
> 
> When you mention 'Sun Partition' what file-system are you specifying?
> 
> ZFS?
> UFS?

EXT3, but the sun "partition" support has to be there for grub tools
to even get at the filesystems at all.


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

Re: [PATCH]: grub: Add Sun partition support to grub-probe and grub-fstest.

[Chip Panarchy]

Ah, I see.

Oh, thanks for clearing that up also, David.

Well, I'll make another topic soon, once I've gotten FreeBSDs 64-bit
kernel to boot directly from GRUB2, requesting support for ZFS.

Thanks,

Panarchy

On Mon, Apr 13, 2009 at 5:43 PM, Felix Zielcke  wrote:
> Am Montag, den 13.04.2009, 17:40 +1000 schrieb Chip Panarchy:
>> Hello
>>
>> When you mention 'Sun Partition' what file-system are you specifying?
>>
>> ZFS?
>> UFS?
>>
>
> He surely meant Sun partition table format and not a filesystem. Grub2
> doestn't support ZFS
> Sun seems to have it's own partition table format just like pc (or
> msdos) /gpt/apple/amiga/acorn which grub2 supports.
> --
> Felix Zielcke
>
>
>
> ___
> 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: [PATCH] FreeBSD 64-bit kernel support

[Joey Korkames]

Figured it out, 
s/multiboot_mod-loader_i386_multiboot_helper/bsd_mod-loader_i386_bsd_helper/ 
and bingo!


Worked ion both Xen HVM and on a real amd64 box (over PXE)

Yay GRUB2 and its devs!
-joey

Joey Korkames writes:

I can't make grub2 build with phcoder's bsd64.diff. My guess it is beacuse conf/i386.mk is missing stuff related to 
loader/i386/bsd_helper.S $(loader/i386/bsd_helper.S_DEPENDENCIES)?, but I wouldn't how or where to add it in.


 
phcoder writes:


Bean kindly allowed me to mess with this patch. So here comes an 
improved version. I moved helpers out of the kernels. Because of how 
FreeBSD expects the initial virtual memory mapping only first GB of 
physical memory is accessible so it was required to use of trampoline 
technique.


diff --git a/conf/i386-pc.mk b/conf/i386-pc.mk
index ab14e08..806ea10 100644
--- a/conf/i386-pc.mk
+++ b/conf/i386-pc.mk
@@ -2575,13 +2575,13 @@ aout_mod_CFLAGS = $(COMMON_CFLAGS)
 aout_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
 # For bsd.mod
-bsd_mod_SOURCES = loader/i386/bsd.c
-CLEANFILES += bsd.mod mod-bsd.o mod-bsd.c pre-bsd.o bsd_mod-loader_i386_bsd.o und-bsd.lst
+bsd_mod_SOURCES = loader/i386/bsd.c loader/i386/bsd_helper.S
+CLEANFILES += bsd.mod mod-bsd.o mod-bsd.c pre-bsd.o bsd_mod-loader_i386_bsd.o bsd_mod-loader_i386_bsd_helper.o und-bsd.lst
 ifneq ($(bsd_mod_EXPORTS),no)
 CLEANFILES += def-bsd.lst
 DEFSYMFILES += def-bsd.lst
 endif
-MOSTLYCLEANFILES += bsd_mod-loader_i386_bsd.d
+MOSTLYCLEANFILES += bsd_mod-loader_i386_bsd.d bsd_mod-loader_i386_bsd.d
 UNDSYMFILES += und-bsd.lst
 
 bsd.mod: pre-bsd.o mod-bsd.o $(TARGET_OBJ2ELF)
@@ -2590,9 +2590,9 @@ bsd.mod: pre-bsd.o mod-bsd.o $(TARGET_OBJ2ELF)
 	if test ! -z $(TARGET_OBJ2ELF); then ./$(TARGET_OBJ2ELF) $@ || (rm -f $@; exit 1); fi
 	$(STRIP) --strip-unneeded -K grub_mod_init -K grub_mod_fini -K _grub_mod_init -K _grub_mod_fini -R .note -R .comment $@
 
-pre-bsd.o: $(bsd_mod_DEPENDENCIES) bsd_mod-loader_i386_bsd.o
+pre-bsd.o: $(bsd_mod_DEPENDENCIES) bsd_mod-loader_i386_bsd.o bsd_mod-loader_i386_bsd_helper.o
 	-rm -f $@
-	$(TARGET_CC) $(bsd_mod_LDFLAGS) $(TARGET_LDFLAGS) -Wl,-r,-d -o $@ bsd_mod-loader_i386_bsd.o
+	$(TARGET_CC) $(bsd_mod_LDFLAGS) $(TARGET_LDFLAGS) -Wl,-r,-d -o $@ bsd_mod-loader_i386_bsd.o bsd_mod-loader_i386_bsd_helper.o
 
 mod-bsd.o: mod-bsd.c
 	$(TARGET_CC) $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) $(bsd_mod_CFLAGS) -c -o $@ $<
@@ -2628,6 +2628,24 @@ partmap-bsd_mod-loader_i386_bsd.lst: loader/i386/bsd.c $(loader/i386/bsd.c_DEPEN
 	set -e; 	  $(TARGET_CC) -Iloader/i386 -I$(srcdir)/loader/i386 $(TARGET_CPPFLAGS)  $(TARGET_CFLAGS) $(bsd_mod_CFLAGS) -E $< 	  | sh $(srcdir)/genpartmaplist.sh bsd > $@ || (rm -f $@; exit 1)
 
 
+bsd_mod-loader_i386_bsd_helper.o: loader/i386/bsd_helper.S $(loader/i386/bsd_helper.S_DEPENDENCIES)
+	$(TARGET_CC) -Iloader/i386 -I$(srcdir)/loader/i386 $(TARGET_CPPFLAGS) -DASM_FILE=1 $(TARGET_ASFLAGS) $(multiboot_mod_ASFLAGS) -MD -c -o $@ $<
+-include bsd_mod-loader_i386_bsd_helper.d
+
+CLEANFILES += cmd-bsd_mod-loader_i386_bsd_helper.lst fs-bsd_mod-loader_i386_bsd_helper.lst partmap-bsd_mod-loader_i386_bsd_helper.lst
+COMMANDFILES += cmd-bsd_mod-loader_i386_bsd_helper.lst
+FSFILES += fs-bsd_mod-loader_i386_bsd_helper.lst
+PARTMAPFILES += partmap-bsd_mod-loader_i386_bsd_helper.lst
+
+cmd-bsd_mod-loader_i386_bsd_helper.lst: loader/i386/multiboot_helper.S $(loader/i386/multiboot_helper.S_DEPENDENCIES) gencmdlist.sh
+	set -e; 	  $(TARGET_CC) -Iloader/i386 -I$(srcdir)/loader/i386 $(TARGET_CPPFLAGS) -DASM_FILE=1 $(TARGET_ASFLAGS) $(multiboot_mod_ASFLAGS) -E $< 	  | sh $(srcdir)/gencmdlist.sh bsd > $@ || (rm -f $@; exit 1)
+
+fs-bsd_mod-loader_i386_bsd_helper.lst: loader/i386/multiboot_helper.S $(loader/i386/multiboot_helper.S_DEPENDENCIES) genfslist.sh
+	set -e; 	  $(TARGET_CC) -Iloader/i386 -I$(srcdir)/loader/i386 $(TARGET_CPPFLAGS) -DASM_FILE=1 $(TARGET_ASFLAGS) $(multiboot_mod_ASFLAGS) -E $< 	  | sh $(srcdir)/genfslist.sh bsd > $@ || (rm -f $@; exit 1)
+
+partmap-bsd_mod-loader_i386_bsd_helper.lst: loader/i386/multiboot_helper.S $(loader/i386/multiboot_helper.S_DEPENDENCIES) genpartmaplist.sh
+	set -e; 	  $(TARGET_CC) -Iloader/i386 -I$(srcdir)/loader/i386 $(TARGET_CPPFLAGS) -DASM_FILE=1 $(TARGET_ASFLAGS) $(multiboot_mod_ASFLAGS) -E $< 	  | sh $(srcdir)/genpartmaplist.sh bsd > $@ || (rm -f $@; exit 1)
+
 bsd_mod_CFLAGS = $(COMMON_CFLAGS)
 bsd_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH]: grub: Add Sun partition support to grub-probe and grub-fstest.

[phcoder]

Please don't start developement of grub-zfs because I'm already doing 
some stuff on it. It would be pity to duplicate the work

Chip Panarchy wrote:

Ah, I see.

Oh, thanks for clearing that up also, David.

Well, I'll make another topic soon, once I've gotten FreeBSDs 64-bit
kernel to boot directly from GRUB2, requesting support for ZFS.

Thanks,

Panarchy

On Mon, Apr 13, 2009 at 5:43 PM, Felix Zielcke  wrote:

Am Montag, den 13.04.2009, 17:40 +1000 schrieb Chip Panarchy:

Hello

When you mention 'Sun Partition' what file-system are you specifying?

ZFS?
UFS?


He surely meant Sun partition table format and not a filesystem. Grub2
doestn't support ZFS
Sun seems to have it's own partition table format just like pc (or
msdos) /gpt/apple/amiga/acorn which grub2 supports.
--
Felix Zielcke



___
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



--

Regards
Vladimir 'phcoder' Serbinenko


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

Re: [PATCH]: grub: Add sparc64 Linux kernel loader support.

[phcoder]

Really nice. I have no way of testing it but if it works it means that 
sparc64 port now has real life. We could even proclaim April, the 13th 
the annual GRUB2 SPARC64 day

David Miller wrote:

This adds the sparc64 loader for Linux kernels.

Committed.

2009-04-13 David S. Miller 

* include/grub/sparc64/ieee1275/loader.h: New file.
* include/grub/sparc64/ieee1275/memory.h: Likewise.
* include/grub/sparc64/kernel.h: Likewise.
* loader/sparc64/ieee1275/linux.c: Likewise.
---
 include/grub/sparc64/ieee1275/loader.h |   27 ++
 include/grub/sparc64/ieee1275/memory.h |   24 ++
 include/grub/sparc64/kernel.h  |   30 ++
 loader/sparc64/ieee1275/linux.c|  514 
 4 files changed, 595 insertions(+), 0 deletions(-)
 create mode 100644 include/grub/sparc64/ieee1275/loader.h
 create mode 100644 include/grub/sparc64/ieee1275/memory.h
 create mode 100644 include/grub/sparc64/kernel.h
 create mode 100644 loader/sparc64/ieee1275/linux.c

diff --git a/include/grub/sparc64/ieee1275/loader.h 
b/include/grub/sparc64/ieee1275/loader.h
new file mode 100644
index 000..12bb2a6
--- /dev/null
+++ b/include/grub/sparc64/ieee1275/loader.h
@@ -0,0 +1,27 @@
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2009  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see .
+ */
+
+#ifndef GRUB_LOADER_MACHINE_HEADER
+#define GRUB_LOADER_MACHINE_HEADER 1
+
+/* The symbol shared between the normal mode and rescue mode
+   loader.  */
+void grub_rescue_cmd_linux (int argc, char *argv[]);
+void grub_rescue_cmd_initrd (int argc, char *argv[]);
+
+#endif /* ! GRUB_LOADER_MACHINE_HEADER */
diff --git a/include/grub/sparc64/ieee1275/memory.h 
b/include/grub/sparc64/ieee1275/memory.h
new file mode 100644
index 000..c997f66
--- /dev/null
+++ b/include/grub/sparc64/ieee1275/memory.h
@@ -0,0 +1,24 @@
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2009 Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see .
+ */
+
+#ifndef GRUB_MEMORY_MACHINE_HEADER
+#define GRUB_MEMORY_MACHINE_HEADER 1
+
+#define GRUB_MACHINE_MEMORY_AVAILABLE  1
+
+#endif
diff --git a/include/grub/sparc64/kernel.h b/include/grub/sparc64/kernel.h
new file mode 100644
index 000..9f404b0
--- /dev/null
+++ b/include/grub/sparc64/kernel.h
@@ -0,0 +1,30 @@
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2005,2006,2007,2008  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see .
+ */
+
+#ifndef GRUB_KERNEL_CPU_HEADER
+#define GRUB_KERNEL_CPU_HEADER 1
+
+#define GRUB_MOD_ALIGN 0x2000
+
+/* Non-zero value is only needed for PowerMacs.  */
+#define GRUB_MOD_GAP 0x0
+
+#define GRUB_KERNEL_CPU_PREFIX 0x2
+#define GRUB_KERNEL_CPU_DATA_END   0x42
+
+#endif
diff --git a/loader/sparc64/ieee1275/linux.c b/loader/sparc64/ieee1275/linux.c
new file mode 100644
index 000..4912b97
--- /dev/null
+++ b/loader/sparc64/ieee1275/linux.c
@@ -0,0 +1,514 @@
+/* linux.c - boot Linux */
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2003, 2004, 2005, 2007, 2009  Free Software Foundation, Inc.
+ *
+ *  GRUB is fre

Re: [PATCH] FreeBSD 64-bit kernel support

[phcoder]

It seems that your build system wasn't up-to-date. The possible fix is:
make maintainer-clean
./autogen.sh

Joey Korkames wrote:
Figured it out, 
s/multiboot_mod-loader_i386_multiboot_helper/bsd_mod-loader_i386_bsd_helper/ 
and bingo!


Worked ion both Xen HVM and on a real amd64 box (over PXE)

Yay GRUB2 and its devs!
-joey

Joey Korkames writes:

I can't make grub2 build with phcoder's bsd64.diff. My guess it is 
beacuse conf/i386.mk is missing stuff related to 
loader/i386/bsd_helper.S $(loader/i386/bsd_helper.S_DEPENDENCIES)?, 
but I wouldn't how or where to add it in.


 
phcoder writes:


Bean kindly allowed me to mess with this patch. So here comes an 
improved version. I moved helpers out of the kernels. Because of how 
FreeBSD expects the initial virtual memory mapping only first GB of 
physical memory is accessible so it was required to use of trampoline 
technique.





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



--

Regards
Vladimir 'phcoder' Serbinenko


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

Re: [PATCH] FreeBSD 64-bit kernel support

[phcoder]

Joey Korkames wrote:
Hmm, FreeBSD seems to choke when trying to load the grub-bootstrapped 
mfsroot.gz (as the root device - haven't tried loading without rooting 
from it)...

Thank you for the testing. Can you define "choke" more exactly?


This is a custom mfsroot, booted like so:
menuentry "FreeBSD 7.1-STABLE amd64" {
  freebsd /osstore/STAGE2/FREEBSD/amd64/kernel.gz Dh
  freebsd_loadenv /osstore/STAGE2/FREEBSD/amd64/device.hints
  freebsd_module /osstore/STAGE2/FREEBSD/amd64/mfsroot.gz type=mfs_root
  set FreeBSD.vfs.root.mountfrom=ufs:/dev/md0
}

perhaps I'll try with the Sysinstall floppy's mfsroot - it might be a 
little smaller.


PS. A correction for that last patch:
-MOSTLYCLEANFILES += bsd_mod-loader_i386_bsd.d bsd_mod-loader_i386_bsd.d
+MOSTLYCLEANFILES += bsd_mod-loader_i386_bsd.d 
bsd_mod-loader_i386_bsd_helper.d


Just run commands I gave you. You also need ruby to regenerate all these 
autogenerated files.

Thanks
joey

Joey Korkames writes:

Figured it out, 
s/multiboot_mod-loader_i386_multiboot_helper/bsd_mod-loader_i386_bsd_helper/ 
and bingo!


Worked ion both Xen HVM and on a real amd64 box (over PXE)

Yay GRUB2 and its devs!
-joey

Joey Korkames writes:

I can't make grub2 build with phcoder's bsd64.diff. My guess it is 
beacuse conf/i386.mk is missing stuff related to 
loader/i386/bsd_helper.S $(loader/i386/bsd_helper.S_DEPENDENCIES)?, 
but I wouldn't how or where to add it in.


 
phcoder writes:


Bean kindly allowed me to mess with this patch. So here comes an 
improved version. I moved helpers out of the kernels. Because of how 
FreeBSD expects the initial virtual memory mapping only first GB of 
physical memory is accessible so it was required to use of 
trampoline technique.






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



--

Regards
Vladimir 'phcoder' Serbinenko


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

Re: [PATCH] FreeBSD 64-bit kernel support

[Joey Korkames]

phcoder writes:


Joey Korkames wrote:
Hmm, FreeBSD seems to choke when trying to load the grub-bootstrapped 
mfsroot.gz (as the root device - haven't tried loading without rooting 
from it)...



Thank you for the testing. Can you define "choke" more exactly?




Hmm, did my log attachment not make it? I'll inline it below.

"md0: Preloaded image  11771904 bytes at 0x7380afd000"
I gunzipped the mfsroot.gz on my PXE server, this reported size matches the 
uncompressed mfsroot file.




Just run commands I gave you. You also need ruby to regenerate all these 
autogenerated files.


All things Ruby (including the *.rmk files) purposefully try to escape my 
attention ;-)
adding maintainer-clean before autogen in my build scripts fixed the issue 
-thanks.


"Choking":

Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
   The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-RELEASE #0: Thu Jan  1 08:58:24 UTC 2009
   r...@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(R) CPU5140  @ 2.33GHz (2333.35-MHz K8-class CPU)
 Origin = "GenuineIntel"  Id = 0x6f6  Stepping = 6
 
Features=0xbfebfbff
 Features2=0x4e3bd
 AMD Features=0x2800
 AMD Features2=0x1
 Cores per package: 2
usable memory = 17155354624 (16360 MB)
avail memory  = 16608129024 (15838 MB)
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): APIC ID:  0
cpu1 (AP): APIC ID:  1
ioapic0  irqs 0-23 on motherboard
ioapic1  irqs 24-47 on motherboard
kbd1 at kbdmux0
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
acpi0:  on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  at device 2.0 on pci0
pci1:  on pcib1
pcib2:  irq 16 at device 0.0 on pci1
pci2:  on pcib2
pcib3:  irq 16 at device 0.0 on pci2
pci3:  on pcib3
pcib4:  at device 0.0 on pci3
pci4:  on pcib4
ahd0:  port 0x2400-0x24ff,0x2000-0x20ff 
mem 0xc820-0xc8201fff irq 16 at device 2.0 on pci4
ahd0: [ITHREAD]
aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs
ahd1:  port 0x2c00-0x2cff,0x2800-0x28ff 
mem 0xc8202000-0xc8203fff irq 17 at device 2.1 on pci4
ahd1: [ITHREAD]
aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs
pcib5:  at device 0.2 on pci3
pci5:  on pcib5
pcib6:  irq 18 at device 2.0 on pci2
pci6:  on pcib6
em0:  port 0x3000-0x301f mem 
0xc830-0xc831 irq 18 at device 0.0 on pci6
em0: Using MSI interrupt
em0: [FILTER]
em0: Ethernet address: 00:30:48:31:6b:10
em1:  port 0x3020-0x303f mem 
0xc832-0xc833 irq 19 at device 0.1 on pci6
em1: Using MSI interrupt
em1: [FILTER]
em1: Ethernet address: 00:30:48:31:6b:11
pcib7:  at device 0.3 on pci1
pci7:  on pcib7
mpt0:  port 0x4000-0x40ff mem 
0xc841-0xc8413fff,0xc840-0xc840 irq 24 at device 1.0 on pci7
mpt0: [ITHREAD]
mpt0: MPI Version=1.5.13.0
mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 )
mpt0: 0 Active Volumes (2 Max)
mpt0: 0 Hidden Drive Members (10 Max)
pcib8:  at device 4.0 on pci0
pci8:  on pcib8
pcib9:  at device 6.0 on pci0
pci9:  on pcib9
pci0:  at device 8.0 (no driver attached)
pcib10:  irq 17 at device 28.0 on pci0
pci10:  on pcib10
uhci0:  port 0x1800-0x181f irq 
17 at device 29.0 on pci0
uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0:  on uhci0
usb0: USB revision 1.0
uhub0:  on usb0
uhub0: 2 ports with 2 removable, self powered
uhci1:  port 0x1820-0x183f irq 
19 at device 29.1 on pci0
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1:  on uhci1
usb1: USB revision 1.0
uhub1:  on usb1
uhub1: 2 ports with 2 removable, self powered
uhci2:  port 0x1840-0x185f irq 
18 at device 29.2 on pci0
uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb2:  on uhci2
usb2: USB revision 1.0
uhub2:  on usb2
uhub2: 2 ports with 2 removable, self powered
ehci0:  mem 0xc800-0xc80003ff irq 17 at 
device 29.7 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb3: EHCI version 1.0
usb3: companion controllers, 2 ports each: usb0 usb1 usb2
usb3:  on ehci0
usb3: USB revision 2.0
uhub3:  on usb3
uhub3: 6 ports with 6 removable, self powered
pcib11:  at device 30.0 on pci0
pci11:  on pcib11
vgapci0:  port 0x5000-0x50ff mem 
0xd000-0xd7ff,0xc850-0xc850 irq 18 at device 1.0 on pci11
isab0:  at device 31.0 on pci0
isa0:  on isab0
atapci0:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0
ata0:  on atapci0
ata0: [ITHREAD]
ata1:  on atapci0
ata1: [ITHREAD]
pci0:  at device 31.3 (no driver attached)
acpi_button0:  on acpi0
atkbdc0:  port 0x60,0x64 irq 1 on acpi0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
sio0: configured irq 4 not in bitmap of probed irq

Re: [PATCH] FreeBSD 64-bit kernel support

[phcoder]

Hello, I know where you problem comes from I'll try to fix it now.
Joey Korkames wrote:

phcoder writes:


Joey Korkames wrote:
Hmm, FreeBSD seems to choke when trying to load the grub-bootstrapped 
mfsroot.gz (as the root device - haven't tried loading without 
rooting from it)...



Thank you for the testing. Can you define "choke" more exactly?




Hmm, did my log attachment not make it? I'll inline it below.

"md0: Preloaded image  11771904 bytes at 0x7380afd000"
I gunzipped the mfsroot.gz on my PXE server, this reported size matches 
the uncompressed mfsroot file.




Just run commands I gave you. You also need ruby to regenerate all 
these autogenerated files.


All things Ruby (including the *.rmk files) purposefully try to escape 
my attention ;-)
adding maintainer-clean before autogen in my build scripts fixed the 
issue -thanks.



"Choking":

Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
   The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-RELEASE #0: Thu Jan  1 08:58:24 UTC 2009
   r...@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(R) CPU5140  @ 2.33GHz (2333.35-MHz 
K8-class CPU)

 Origin = "GenuineIntel"  Id = 0x6f6  Stepping = 6
 Features=0xbfebfbff 

 Features2=0x4e3bd 


 AMD Features=0x2800
 AMD Features2=0x1
 Cores per package: 2
usable memory = 17155354624 (16360 MB)
avail memory  = 16608129024 (15838 MB)
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): APIC ID:  0
cpu1 (AP): APIC ID:  1
ioapic0  irqs 0-23 on motherboard
ioapic1  irqs 24-47 on motherboard
kbd1 at kbdmux0
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
acpi0:  on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  at device 2.0 on pci0
pci1:  on pcib1
pcib2:  irq 16 at device 0.0 on pci1
pci2:  on pcib2
pcib3:  irq 16 at device 0.0 on pci2
pci3:  on pcib3
pcib4:  at device 0.0 on pci3
pci4:  on pcib4
ahd0:  port 
0x2400-0x24ff,0x2000-0x20ff mem 0xc820-0xc8201fff irq 16 at device 
2.0 on pci4

ahd0: [ITHREAD]
aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs
ahd1:  port 
0x2c00-0x2cff,0x2800-0x28ff mem 0xc8202000-0xc8203fff irq 17 at device 
2.1 on pci4

ahd1: [ITHREAD]
aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs
pcib5:  at device 0.2 on pci3
pci5:  on pcib5
pcib6:  irq 18 at device 2.0 on pci2
pci6:  on pcib6
em0:  port 0x3000-0x301f mem 
0xc830-0xc831 irq 18 at device 0.0 on pci6

em0: Using MSI interrupt
em0: [FILTER]
em0: Ethernet address: 00:30:48:31:6b:10
em1:  port 0x3020-0x303f mem 
0xc832-0xc833 irq 19 at device 0.1 on pci6

em1: Using MSI interrupt
em1: [FILTER]
em1: Ethernet address: 00:30:48:31:6b:11
pcib7:  at device 0.3 on pci1
pci7:  on pcib7
mpt0:  port 0x4000-0x40ff mem 
0xc841-0xc8413fff,0xc840-0xc840 irq 24 at device 1.0 on pci7

mpt0: [ITHREAD]
mpt0: MPI Version=1.5.13.0
mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 )
mpt0: 0 Active Volumes (2 Max)
mpt0: 0 Hidden Drive Members (10 Max)
pcib8:  at device 4.0 on pci0
pci8:  on pcib8
pcib9:  at device 6.0 on pci0
pci9:  on pcib9
pci0:  at device 8.0 (no driver attached)
pcib10:  irq 17 at device 28.0 on pci0
pci10:  on pcib10
uhci0:  port 
0x1800-0x181f irq 17 at device 29.0 on pci0

uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0:  on uhci0
usb0: USB revision 1.0
uhub0:  on usb0
uhub0: 2 ports with 2 removable, self powered
uhci1:  port 
0x1820-0x183f irq 19 at device 29.1 on pci0

uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1:  on uhci1
usb1: USB revision 1.0
uhub1:  on usb1
uhub1: 2 ports with 2 removable, self powered
uhci2:  port 
0x1840-0x185f irq 18 at device 29.2 on pci0

uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb2:  on uhci2
usb2: USB revision 1.0
uhub2:  on usb2
uhub2: 2 ports with 2 removable, self powered
ehci0:  mem 0xc800-0xc80003ff irq 
17 at device 29.7 on pci0

ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb3: EHCI version 1.0
usb3: companion controllers, 2 ports each: usb0 usb1 usb2
usb3:  on ehci0
usb3: USB revision 2.0
uhub3:  on usb3
uhub3: 6 ports with 6 removable, self powered
pcib11:  at device 30.0 on pci0
pci11:  on pcib11
vgapci0:  port 0x5000-0x50ff mem 
0xd000-0xd7ff,0xc850-0xc850 irq 18 at device 1.0 on pci11

isab0:  at device 31.0 on pci0
isa0:  on isab0
atapci0:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0

ata0:  on atapci0
ata0: [ITHREAD]
ata1:  on atapci0
ata1: [ITHREAD]
pci0:  at device 31.3 (no driver attached)
acpi_button0:  on acpi0
atkbdc0:  port 0x60,0x64 irq 1 on acpi0
atkbd0:  irq 1 on atkbd

Nightly build script

[phcoder]

Hello, here is a first proposition of a script for nightly builds. On 
IRC Yoshinori K. Okuji said that grub.enbug.org could be used to host 
these files. Can this server do the builds too? If not can someone setup 
build factory?

--

Regards
Vladimir 'phcoder' Serbinenko


autocompile.sh
Description: Bourne shell script
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] FreeBSD 64-bit kernel support

[Joey Korkames]

Hmm, FreeBSD seems to choke when trying to load the 
grub-bootstrapped mfsroot.gz (as the root device - haven't tried loading 
without rooting from it)...


This is a custom mfsroot, booted like so:
menuentry "FreeBSD 7.1-STABLE amd64" {
  freebsd /osstore/STAGE2/FREEBSD/amd64/kernel.gz Dh
  freebsd_loadenv /osstore/STAGE2/FREEBSD/amd64/device.hints
  freebsd_module /osstore/STAGE2/FREEBSD/amd64/mfsroot.gz type=mfs_root
  set FreeBSD.vfs.root.mountfrom=ufs:/dev/md0
}

perhaps I'll try with the Sysinstall floppy's mfsroot - it might be a little 
smaller.


PS. A correction for that last patch:
-MOSTLYCLEANFILES += bsd_mod-loader_i386_bsd.d bsd_mod-loader_i386_bsd.d
+MOSTLYCLEANFILES += bsd_mod-loader_i386_bsd.d bsd_mod-loader_i386_bsd_helper.d

Thanks
joey

Joey Korkames writes:

Figured it out, 
s/multiboot_mod-loader_i386_multiboot_helper/bsd_mod-loader_i386_bsd_helper/ 
and bingo!


Worked ion both Xen HVM and on a real amd64 box (over PXE)

Yay GRUB2 and its devs!
-joey

Joey Korkames writes:

I can't make grub2 build with phcoder's bsd64.diff. My guess it is beacuse conf/i386.mk is missing stuff related to 
loader/i386/bsd_helper.S $(loader/i386/bsd_helper.S_DEPENDENCIES)?, but I wouldn't how or where to add it in.


 
phcoder writes:


Bean kindly allowed me to mess with this patch. So here comes an 
improved version. I moved helpers out of the kernels. Because of how 
FreeBSD expects the initial virtual memory mapping only first GB of 
physical memory is accessible so it was required to use of trampoline 
technique.


Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-RELEASE #0: Thu Jan  1 08:58:24 UTC 2009
r...@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(R) CPU5140  @ 2.33GHz (2333.35-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x6f6  Stepping = 6
  
Features=0xbfebfbff
  Features2=0x4e3bd
  AMD Features=0x2800
  AMD Features2=0x1
  Cores per package: 2
usable memory = 17155354624 (16360 MB)
avail memory  = 16608129024 (15838 MB)
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0  irqs 0-23 on motherboard
ioapic1  irqs 24-47 on motherboard
kbd1 at kbdmux0
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
acpi0:  on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  at device 2.0 on pci0
pci1:  on pcib1
pcib2:  irq 16 at device 0.0 on pci1
pci2:  on pcib2
pcib3:  irq 16 at device 0.0 on pci2
pci3:  on pcib3
pcib4:  at device 0.0 on pci3
pci4:  on pcib4
ahd0:  port 0x2400-0x24ff,0x2000-0x20ff 
mem 0xc820-0xc8201fff irq 16 at device 2.0 on pci4
ahd0: [ITHREAD]
aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs
ahd1:  port 0x2c00-0x2cff,0x2800-0x28ff 
mem 0xc8202000-0xc8203fff irq 17 at device 2.1 on pci4
ahd1: [ITHREAD]
aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs
pcib5:  at device 0.2 on pci3
pci5:  on pcib5
pcib6:  irq 18 at device 2.0 on pci2
pci6:  on pcib6
em0:  port 0x3000-0x301f mem 
0xc830-0xc831 irq 18 at device 0.0 on pci6
em0: Using MSI interrupt
em0: [FILTER]
em0: Ethernet address: 00:30:48:31:6b:10
em1:  port 0x3020-0x303f mem 
0xc832-0xc833 irq 19 at device 0.1 on pci6
em1: Using MSI interrupt
em1: [FILTER]
em1: Ethernet address: 00:30:48:31:6b:11
pcib7:  at device 0.3 on pci1
pci7:  on pcib7
mpt0:  port 0x4000-0x40ff mem 
0xc841-0xc8413fff,0xc840-0xc840 irq 24 at device 1.0 on pci7
mpt0: [ITHREAD]
mpt0: MPI Version=1.5.13.0
mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 )
mpt0: 0 Active Volumes (2 Max)
mpt0: 0 Hidden Drive Members (10 Max)
pcib8:  at device 4.0 on pci0
pci8:  on pcib8
pcib9:  at device 6.0 on pci0
pci9:  on pcib9
pci0:  at device 8.0 (no driver attached)
pcib10:  irq 17 at device 28.0 on pci0
pci10:  on pcib10
uhci0:  port 0x1800-0x181f irq 
17 at device 29.0 on pci0
uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0:  on uhci0
usb0: USB revision 1.0
uhub0:  on usb0
uhub0: 2 ports with 2 removable, self powered
uhci1:  port 0x1820-0x183f irq 
19 at device 29.1 on pci0
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1:  on uhci1
usb1: USB revision 1.0
uhub1:  on usb1
uhub1: 2 ports with 2 removable, self powered
uhci2:  port 0x1840-0x185f irq 
18 at device 29.2 on pci0
uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb2:  on uhci2
usb2: USB revision 1.0
uhub2:  on usb2
uhub2: 2 ports with 2 removable, self powered
ehci0:  mem 0xc800-0xc80003ff irq 17 at 
device 29.7 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]

Re: [PATCH] remove BSD partition number from install_drive/grub_drive in grub-install

[phcoder]

Hello, I'm sorry if my responses have been a bit rude too.
Chip Panarchy wrote:

You're right.

Once I have all my operating systems installed, working correctly,
have successfully created my 2 Linux distributions, have some time off
(starting work tomorrow!), then I will learn some C++, and help with
the development of software like GRUB2.


grub2 doesn't use any C++, only pure C

Please continue helping me out PHcoder.
You once spoke about xnu code for grub2. I'm happy to announce that this 
code is near its completion. I have some strange bugs in it and some 
incompletenesses but code itself already works


Thanks in advance,

Panarchy

On Sun, Apr 12, 2009 at 8:39 PM, phcoder  wrote:

Please, don't bother developers with same request in multiple threads. Not
only it doesn't help to promote your suggestion but is also annoying. I feel
it is actually unnice how you push your suggestions hardly without offering
any help in developement
Chip Panarchy wrote:

Hi

Ah, interesting.

I've been trying to get a feature added to GRUB2 to do with
FreeBSD-amd64. That is to give GRUB2 the feature which allows for
direct 'calling' of the 64-bit FreeBSD kernel. GRUB2 currently
supports only the 32-bit version.

If you have the skill, and the time, can you please give a go
implementing the above feature(s)?

Thanks in advance,

Panarchy

On Sun, Apr 12, 2009 at 5:08 PM, Felix Zielcke  wrote:

Am Sonntag, den 12.04.2009, 09:45 +1000 schrieb Chip Panarchy:

Which BSD?


Debian GNU/kFreeBSD-amd64
--
Felix Zielcke



___
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


--

Regards
Vladimir 'phcoder' Serbinenko


___
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



--

Regards
Vladimir 'phcoder' Serbinenko


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

Re: [PATCH] FreeBSD 64-bit kernel support

[phcoder]

Try this
Joey Korkames wrote:

phcoder writes:


Joey Korkames wrote:
Hmm, FreeBSD seems to choke when trying to load the grub-bootstrapped 
mfsroot.gz (as the root device - haven't tried loading without 
rooting from it)...



Thank you for the testing. Can you define "choke" more exactly?




Hmm, did my log attachment not make it? I'll inline it below.

"md0: Preloaded image  11771904 bytes at 0x7380afd000"
I gunzipped the mfsroot.gz on my PXE server, this reported size matches 
the uncompressed mfsroot file.




Just run commands I gave you. You also need ruby to regenerate all 
these autogenerated files.


All things Ruby (including the *.rmk files) purposefully try to escape 
my attention ;-)
adding maintainer-clean before autogen in my build scripts fixed the 
issue -thanks.



"Choking":

Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
   The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-RELEASE #0: Thu Jan  1 08:58:24 UTC 2009
   r...@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(R) CPU5140  @ 2.33GHz (2333.35-MHz 
K8-class CPU)

 Origin = "GenuineIntel"  Id = 0x6f6  Stepping = 6
 Features=0xbfebfbff 

 Features2=0x4e3bd 


 AMD Features=0x2800
 AMD Features2=0x1
 Cores per package: 2
usable memory = 17155354624 (16360 MB)
avail memory  = 16608129024 (15838 MB)
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): APIC ID:  0
cpu1 (AP): APIC ID:  1
ioapic0  irqs 0-23 on motherboard
ioapic1  irqs 24-47 on motherboard
kbd1 at kbdmux0
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
acpi0:  on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  at device 2.0 on pci0
pci1:  on pcib1
pcib2:  irq 16 at device 0.0 on pci1
pci2:  on pcib2
pcib3:  irq 16 at device 0.0 on pci2
pci3:  on pcib3
pcib4:  at device 0.0 on pci3
pci4:  on pcib4
ahd0:  port 
0x2400-0x24ff,0x2000-0x20ff mem 0xc820-0xc8201fff irq 16 at device 
2.0 on pci4

ahd0: [ITHREAD]
aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs
ahd1:  port 
0x2c00-0x2cff,0x2800-0x28ff mem 0xc8202000-0xc8203fff irq 17 at device 
2.1 on pci4

ahd1: [ITHREAD]
aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs
pcib5:  at device 0.2 on pci3
pci5:  on pcib5
pcib6:  irq 18 at device 2.0 on pci2
pci6:  on pcib6
em0:  port 0x3000-0x301f mem 
0xc830-0xc831 irq 18 at device 0.0 on pci6

em0: Using MSI interrupt
em0: [FILTER]
em0: Ethernet address: 00:30:48:31:6b:10
em1:  port 0x3020-0x303f mem 
0xc832-0xc833 irq 19 at device 0.1 on pci6

em1: Using MSI interrupt
em1: [FILTER]
em1: Ethernet address: 00:30:48:31:6b:11
pcib7:  at device 0.3 on pci1
pci7:  on pcib7
mpt0:  port 0x4000-0x40ff mem 
0xc841-0xc8413fff,0xc840-0xc840 irq 24 at device 1.0 on pci7

mpt0: [ITHREAD]
mpt0: MPI Version=1.5.13.0
mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 )
mpt0: 0 Active Volumes (2 Max)
mpt0: 0 Hidden Drive Members (10 Max)
pcib8:  at device 4.0 on pci0
pci8:  on pcib8
pcib9:  at device 6.0 on pci0
pci9:  on pcib9
pci0:  at device 8.0 (no driver attached)
pcib10:  irq 17 at device 28.0 on pci0
pci10:  on pcib10
uhci0:  port 
0x1800-0x181f irq 17 at device 29.0 on pci0

uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0:  on uhci0
usb0: USB revision 1.0
uhub0:  on usb0
uhub0: 2 ports with 2 removable, self powered
uhci1:  port 
0x1820-0x183f irq 19 at device 29.1 on pci0

uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1:  on uhci1
usb1: USB revision 1.0
uhub1:  on usb1
uhub1: 2 ports with 2 removable, self powered
uhci2:  port 
0x1840-0x185f irq 18 at device 29.2 on pci0

uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb2:  on uhci2
usb2: USB revision 1.0
uhub2:  on usb2
uhub2: 2 ports with 2 removable, self powered
ehci0:  mem 0xc800-0xc80003ff irq 
17 at device 29.7 on pci0

ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb3: EHCI version 1.0
usb3: companion controllers, 2 ports each: usb0 usb1 usb2
usb3:  on ehci0
usb3: USB revision 2.0
uhub3:  on usb3
uhub3: 6 ports with 6 removable, self powered
pcib11:  at device 30.0 on pci0
pci11:  on pcib11
vgapci0:  port 0x5000-0x50ff mem 
0xd000-0xd7ff,0xc850-0xc850 irq 18 at device 1.0 on pci11

isab0:  at device 31.0 on pci0
isa0:  on isab0
atapci0:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0

ata0:  on atapci0
ata0: [ITHREAD]
ata1:  on atapci0
ata1: [ITHREAD]
pci0:  at device 31.3 (no driver attached)
acpi_button0:  on acpi0
atkbdc0:  port 0x60,0x64 irq 1 on acpi0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]

Re: [PATCH] remove BSD partition number from install_drive/grub_drive in grub-install

[Chip Panarchy]

Hello

Great, looking forward to its completion.

Panarchy

On Mon, Apr 13, 2009 at 7:08 PM, phcoder  wrote:
> Hello, I'm sorry if my responses have been a bit rude too.
> Chip Panarchy wrote:
>>
>> You're right.
>>
>> Once I have all my operating systems installed, working correctly,
>> have successfully created my 2 Linux distributions, have some time off
>> (starting work tomorrow!), then I will learn some C++, and help with
>> the development of software like GRUB2.
>>
> grub2 doesn't use any C++, only pure C
>>
>> Please continue helping me out PHcoder.
>
> You once spoke about xnu code for grub2. I'm happy to announce that this
> code is near its completion. I have some strange bugs in it and some
> incompletenesses but code itself already works
>>
>> Thanks in advance,
>>
>> Panarchy
>>
>> On Sun, Apr 12, 2009 at 8:39 PM, phcoder  wrote:
>>>
>>> Please, don't bother developers with same request in multiple threads.
>>> Not
>>> only it doesn't help to promote your suggestion but is also annoying. I
>>> feel
>>> it is actually unnice how you push your suggestions hardly without
>>> offering
>>> any help in developement
>>> Chip Panarchy wrote:

 Hi

 Ah, interesting.

 I've been trying to get a feature added to GRUB2 to do with
 FreeBSD-amd64. That is to give GRUB2 the feature which allows for
 direct 'calling' of the 64-bit FreeBSD kernel. GRUB2 currently
 supports only the 32-bit version.

 If you have the skill, and the time, can you please give a go
 implementing the above feature(s)?

 Thanks in advance,

 Panarchy

 On Sun, Apr 12, 2009 at 5:08 PM, Felix Zielcke  wrote:
>
> Am Sonntag, den 12.04.2009, 09:45 +1000 schrieb Chip Panarchy:
>>
>> Which BSD?
>>
> Debian GNU/kFreeBSD-amd64
> --
> Felix Zielcke
>
>
>
> ___
> 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
>>>
>>> --
>>>
>>> Regards
>>> Vladimir 'phcoder' Serbinenko
>>>
>>>
>>> ___
>>> 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
>
>
> --
>
> Regards
> Vladimir 'phcoder' Serbinenko
>
>
> ___
> 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: [PATCH] remove BSD partition number from install_drive/grub_drive in grub-install

[Felix Zielcke]

Am Samstag, den 11.04.2009, 23:52 +0200 schrieb Felix Zielcke:
> Hi,
> 
> on BSD grub-install thinks that you're wanting to do a cross-install
> when in fact you won't.
> The problem is that in install_drive the BSD partition number isn't
> removed before doing the cross-install check.
> I'm not sure if the regexp is okay so or if it could be better, but at
> least it works for me.

I commited this now.
All other variants of the regexp I tried didn't work except that one.
-- 
Felix Zielcke



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

Re: [PATCH]: grub: Add Sun partition support to grub-probe and grub-fstest.

[Pavel Roskin]

On Sun, 2009-04-12 at 23:53 -0700, David Miller wrote:
> Should be self-explanatory, these tools will be used on sparc64 just
> like they are on i386-pc

Fine with me.

-- 
Regards,
Pavel Roskin


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

[PATCH] fix grub-setup on kfreebsd by adding 0x10 to the sysctl ("kern.geom.debugflags") flags

[Felix Zielcke]

Here's a patch to fix grub-setup on Debian GNU/kFreeBSD.
Without it, it fails always with `grub-setup: error: cannot open
`/dev/da0' in open_device()'
With it, it works fine.

-- 
Felix Zielcke



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

Re: [PATCH] framework for building modules externally

[Robert Millan]

On Sat, Apr 11, 2009 at 01:19:14AM +0200, phcoder wrote:
> Robert Millan wrote:
>> On Wed, Nov 05, 2008 at 07:57:38AM +0100, Christian Franke wrote:
>>> Alternative: Export a symbol describing the ABI version in kernel  
>>> ("grub_abi_3_14").
>>
>> That requires more bytes than a 32-bit integer.
> You export grub_abi anyway. _3_14 is 4 bytes instead of 4 but saves.  
> grub_abi_* can be a fictive variable by adding something like
>   {"grub_abi_<..>", 0},
> to gensymlist.sh.in

I've been thinking that this doesn't solve all the problems anyway.

*.lst files are generated in official grub tree, and it's not easy for
external packages to override that.  Perhaps we should do it at the
source level and not bother about ABI anymore... :-/

-- 
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] Faster text rendering by optimizing font glyph lookup

[Robert Millan]

On Sat, Apr 11, 2009 at 01:39:53AM +0200, phcoder wrote:
> Any reason not to merge this patch?

Probably not.  Btw does Colin need/have an account?

-- 
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] Support up to 256 SCSI disks on Linux

[Robert Millan]

On Sat, Apr 11, 2009 at 01:05:19AM +0200, phcoder wrote:
> Robert Millan wrote:
>> On Wed, Mar 04, 2009 at 10:16:29PM +0100, Robert Millan wrote:
else if (major == SCSI_DISK0_MAJOR)
 -sprintf (name, "/dev/sd%c", 'a' + minor / 16);
 +grub_util_getdiskname_scsi (name, 0, minor / 16);
 +  else if (major == SCSI_DISK1_MAJOR)
 +grub_util_getdiskname_scsi (name, 1, minor / 16);
 [...]
>>> Can this be factorized somehow?  Space in raid.mod is quite critical; when
>>> used it usually ends up in core.img, which needs to fit in the embed area.
>>
>> Oh, I'm sorry.  I thought you were editting disk/raid.c.  util/raid.c has no
>> size issues.  A macro would still be nice though.
>>
> What about making an array of SCSI_DISK?_MAJOR and then just go through it?

Sounds good.

-- 
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: [Design] nested partitions: Unify grub_partition and grub_disk

[Robert Millan]

On Sat, Apr 11, 2009 at 11:58:05PM +0200, phcoder wrote:
> Ping. Is it ok for me to implement it this way?

I'd really like it if Okuji could give his impression on this one, if
possible.

> phcoder wrote:
>> I forgot to speak about another question: partition naming. I see 2  
>> possibilities
>> 1) purely numeric unified naming scheme. It means that
>> (hd0,1,a) becomes (hd0,1,1)
>> On one hand mixed number-letter scheme is similar to what freebsd uses  
>> but on the other hand numerical scheme is versatile and allows 
>> unlimited nestedness. And I don't see why we would use a scheme 
>> specific to one of many supported OSes.
>> 2) Every partition map is allowed to pick the name that it likes as 
>> long as it contains no comma. In this way we would need to keep  
>> partition-name parsing functions in partitition map modules. It means  
>> that this code would be duplicated. But this scheme is better in the  
>> cases when partition map has no numbering scheme but instead has labels 
>> attached to partitions. But in this case IMO search command should be  
>> used find the partition
>>
>> I personally would prefer the first way
>>> Also an interesting question is how would "has_partitions" field be
>>> handled in this scheme.
>>
>> Just ignored. It's actually used only to optimise some code out based 
>> on the assumption that some media has no partitions. Performance gain 
>> is negligible but if this assumption doesn't hold true grub won't be 
>> able to access the partitions which are really here. Famous example is 
>> a cdrom. Most people would assume that cdrom has no partitions. But on  
>> powerpc bootable cdroms use APM
>>
>>
>>
>
>
> -- 
>
> Regards
> Vladimir 'phcoder' Serbinenko
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

-- 
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] Video mode fixes in linux loader

[Robert Millan]

Hi Pavel,

On Mon, Apr 06, 2009 at 11:34:03AM -0400, Pavel Roskin wrote:
> Hello!
> 
> This is an attempt to fix all issues with the video mode handling in the
> new Linux loader.

Please, in general, when you modify code that has been actively worked on
by someone, try to get that person involved.  If I'm to busy to check the
list at a given time, feel free to CC me or msg me on IRC.  Some things
in your patch were not right.

> First of all, free_page() doesn't belong to grub_linux_unload().  The
> later function is called after the new kernel has been loaded, just
> before the boot.  Thus it obliterates the data set up by the last
> "linux" command if the previous Linux boot failed.
> 
> Instead, free_page() should be called from allocate_pages() to reset not
> only real_mode_mem and prot_mode_mem, but also initrd_mem.

Ok.

> Next problem is that grub_linux_boot() can access linux_vesafb_modes
> with a wrong index.  I believe we should threat modes that don't fit the
> array as text modes.
> 
> I introduced GRUB_LINUX_VID_MODE_VESA_START for the first VESA mode we
> support.  Also, I introduced a macro ARRAY_SIZE to calculate the array
> size.

Ok.

> The default VGA mode is now GRUB_LINUX_VID_MODE_NORMAL, not the mode of
> the kernel we tried to load before.

Ok, BUT if we're already in vesa mode, and we know it works (since we're using
it), there's no point in wasting time only to get a worse mode.

We should just make sure subsequent calls to "linux" command override the
previous one.

> Finally, "vga=ask" is now recognized.

With the new loader, Linux' 16-bit entry code is no longer responsible for
setting vesa modes, therefore vga=ask can't work.  There's no point in
recognizing it (except to warn the user).

-- 
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] Faster text rendering by optimizing font glyph lookup

[Felix Zielcke]

Am Montag, den 13.04.2009, 15:57 +0200 schrieb Robert Millan:
> On Sat, Apr 11, 2009 at 01:39:53AM +0200, phcoder wrote:
> > Any reason not to merge this patch?
> 
> Probably not.  Btw does Colin need/have an account?

Colin has an account and already commit access.
-- 
Felix Zielcke



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

Re: [PATCH] fix grub-setup on kfreebsd by adding 0x10 to the sysctl ("kern.geom.debugflags") flags

[Felix Zielcke]

Am Montag, den 13.04.2009, 15:32 +0200 schrieb Felix Zielcke:
> Here's a patch to fix grub-setup on Debian GNU/kFreeBSD.
> Without it, it fails always with `grub-setup: error: cannot open
> `/dev/da0' in open_device()'
> With it, it works fine.

Args there should be a patch attached. Fixed.
-- 
Felix Zielcke
2009-04-13  Felix Zielcke  

	util/hostdisk.c [__FreeBSD_kernel]: Include  and
	
	(open_device) [__FreeBSD_kernel_]: Use sysctlgetbyname() to add 0x10 to
	`kern.geom.debugflags', before opening the device and reset them afterwards.

Index: util/hostdisk.c
===
--- util/hostdisk.c	(revision 2094)
+++ util/hostdisk.c	(working copy)
@@ -90,6 +90,11 @@ struct hd_geometry
 # include  /* DIOCGMEDIASIZE */
 #endif
 
+#ifdef __FreeBSD_kernel__
+#include 
+#include 
+#endif
+
 struct
 {
   char *drive;
@@ -340,7 +345,24 @@ open_device (const grub_disk_t disk, gru
   sector -= disk->partition->start;
   }
 #else /* ! __linux__ */
+#if defined __FreeBSD_kernel__
+  int sysctl_flags, sysctl_oldflags;
+  size_t sysctl_size = sizeof (sysctl_flags);
+
+  if (sysctlbyname ("kern.geom.debugflags", &sysctl_oldflags, &sysctl_size, NULL, 0))
+grub_util_error ("cannot get current flags of sysctl kern.geom.debugflags");
+  sysctl_flags = sysctl_oldflags |= 0x10;
+  if (sysctlbyname ("kern.geom.debugflags", NULL , 0, &sysctl_flags, sysctl_size))
+grub_util_error ("cannot set flags of sysctl kern.geom.debugflags");
+#endif
+
   fd = open (map[disk->id].device, flags);
+
+#if defined __FreeBSD_kernel__
+  if (sysctlbyname ("kern.geom.debugflags", NULL , 0, &sysctl_oldflags, sysctl_size))
+grub_util_error ("cannot set flags back to the old value for sysctl kern.geom.debugflags");
+#endif
+
   if (fd < 0)
 {
   grub_error (GRUB_ERR_BAD_DEVICE, "cannot open `%s' in open_device()", map[disk->id].device);
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] LUA script engine for grub2

[Robert Millan]

On Tue, Apr 07, 2009 at 10:31:44PM +0800, Bean wrote:
> Hi,
> 
> This patch integrate the LUA script engine to grub2.

Hi,

I don't have any opinion for or against using LUA, but note that we need
approval from Marco or Okuji before we can integrate external code.

-- 
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: Allow to control objcopy '-B' argument from foo.rmk files.

[Robert Millan]

On Sat, Apr 11, 2009 at 01:08:31AM -0700, David Miller wrote:
> index 7dfb854..b4f1353 100644
> --- a/conf/i386-pc.rmk
> +++ b/conf/i386-pc.rmk
> @@ -17,26 +17,31 @@ pkglib_IMAGES = boot.img diskboot.img kernel.img 
> pxeboot.img lnxboot.img \
>  boot_img_SOURCES = boot/i386/pc/boot.S
>  boot_img_ASFLAGS = $(COMMON_ASFLAGS)
>  boot_img_LDFLAGS = $(COMMON_LDFLAGS) $(TARGET_IMG_LDFLAGS) -Wl,-Ttext,7C00
> +boot_img_IMG_FMT = binary

Wait, isn't raw format implicit in the _img_ part of the variable name?

If it was ELF, we'd have boot_elf_..., right?

-- 
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: Removing autogenerated files from svn

[Robert Millan]

On Sun, Apr 12, 2009 at 04:54:21PM -0400, Pavel Roskin wrote:
> On Sun, 2009-04-12 at 11:29 -0700, Colin D Bennett wrote:
> > phcoder wrote on Sunday 12 April 2009:
> > > Hello, we all know how annoying are these autogenerated files. We could
> > > remove it. The main argument against it is that people will not be able
> > > to compile without installing a lot of developement tools. It changes
> > > nothing for the users wanting to modify the code. So I propose to remove
> > > these files but in compensation setup a nightly build server. I'm ready
> > > to supply all necessary scripts to create a source tar.gz with
> > > autogenerated files, binary tar.gz and rescue iso for all platforms
> > > where applicable.
> > 
> > Great idea.  I'd love to see this happen.
> 
> Me too.

Me too.

Okuji, can we agree on it this time?  It's annoying for most people, and
release tarballs can include the autogenerated files, so the ruby dependency
is not a problem for end users.

-- 
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] Video mode fixes in linux loader

[Robert Millan]

On Mon, Apr 13, 2009 at 04:16:57PM +0200, Robert Millan wrote:
> > The default VGA mode is now GRUB_LINUX_VID_MODE_NORMAL, not the mode of
> > the kernel we tried to load before.
> 
> Ok, BUT if we're already in vesa mode, and we know it works (since we're using
> it), there's no point in wasting time only to get a worse mode.
> 
> We should just make sure subsequent calls to "linux" command override the
> previous one.

I think this should do it.  Can you confirm this works for you?

(note: this patch is intentionally missing indentation, for 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."

	* loader/i386/linux.c (grub_linux_boot): Only go back to text
	mode when `vid_mode' wasn't initialized.  Otherwise leave the
	current mode (whatever that is).
	(grub_cmd_linux): Default to `vid_mode = 0' rather than
	`GRUB_LINUX_VID_MODE_NORMAL'.

Index: loader/i386/linux.c
===
--- loader/i386/linux.c	(revision 2097)
+++ loader/i386/linux.c	(working copy)
@@ -331,12 +331,14 @@ grub_linux_boot (void)
   
   params = real_mode_mem;
 
-  if (vid_mode < GRUB_LINUX_VID_MODE_VESA_START ||
-  vid_mode >= GRUB_LINUX_VID_MODE_VESA_START +
-		  ARRAY_SIZE (linux_vesafb_modes))
-grub_video_restore ();
-  else if (vid_mode)
+  if (vid_mode)
 {
+  if (vid_mode < GRUB_LINUX_VID_MODE_VESA_START ||
+	  vid_mode >= GRUB_LINUX_VID_MODE_VESA_START +
+	  ARRAY_SIZE (linux_vesafb_modes))
+	grub_video_restore ();
+  else
+	{
   struct linux_vesafb_mode *linux_mode;
   int depth, flags;
   
@@ -366,6 +368,7 @@ grub_linux_boot (void)
 	  return grub_errno;
 	}
 }
+}
 
   if (! grub_linux_setup_video (params))
 params->have_vga = GRUB_VIDEO_TYPE_VLFB;
@@ -570,8 +573,7 @@ grub_cmd_linux (grub_command_t cmd __att
 	   (unsigned) real_size, (unsigned) prot_size);
 
   /* Look for memory size and video mode specified on the command line.  */
-  vid_mode = GRUB_LINUX_VID_MODE_NORMAL;
-  linux_mem_size = 0;
+  vid_mode = linux_mem_size = 0;
   for (i = 1; i < argc; i++)
 if (grub_memcmp (argv[i], "vga=", 4) == 0)
   {
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] fix grub-setup on kfreebsd by adding 0x10 to the sysctl ("kern.geom.debugflags") flags

[Robert Millan]

On Mon, Apr 13, 2009 at 04:26:19PM +0200, Felix Zielcke wrote:
> +#ifdef __FreeBSD_kernel__

Unfortunately FreeBSD doesn't define __FreeBSD_kernel__, so we need
to check for both macros.

> +#if defined __FreeBSD_kernel__
> +  int sysctl_flags, sysctl_oldflags;
> +  size_t sysctl_size = sizeof (sysctl_flags);

You can add a `const' on this one.

> +  sysctl_flags = sysctl_oldflags |= 0x10;

Shouldn't this be "sysctl_oldflags | 0x10" ?

Btw you can avoid the two subsequent calls if sysctl_flags == sysctl_oldflags.

-- 
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] Video mode fixes in linux loader

[Pavel Roskin]

On Mon, 2009-04-13 at 16:16 +0200, Robert Millan wrote:
> Hi Pavel,
> 
> On Mon, Apr 06, 2009 at 11:34:03AM -0400, Pavel Roskin wrote:
> > Hello!
> > 
> > This is an attempt to fix all issues with the video mode handling in the
> > new Linux loader.
> 
> Please, in general, when you modify code that has been actively worked on
> by someone, try to get that person involved.

I tried, but probably not hard enough.  Sorry.

> > The default VGA mode is now GRUB_LINUX_VID_MODE_NORMAL, not the mode of
> > the kernel we tried to load before.
> 
> Ok, BUT if we're already in vesa mode, and we know it works (since we're using
> it), there's no point in wasting time only to get a worse mode.

Maybe we should introduce another macro, e.g.
GRUB_LINUX_VID_MODE_CURRENT, recognize it in the loader and default to
it.

> We should just make sure subsequent calls to "linux" command override the
> previous one.

Yes, failed loading of one kernel should not affect loading of another
kernel.  That was the most annoying bug, and I hope it's fixed now.

> > Finally, "vga=ask" is now recognized.
> 
> With the new loader, Linux' 16-bit entry code is no longer responsible for
> setting vesa modes, therefore vga=ask can't work.  There's no point in
> recognizing it (except to warn the user).

I agree.  Generally, "vga=random_string" causes an error now.  Perhaps
any unrecognized values of "vga" should cause a warning, not an error.

-- 
Regards,
Pavel Roskin


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

Re: [PATCH] fix grub-setup on kfreebsd by adding 0x10 to the sysctl ("kern.geom.debugflags") flags

[Felix Zielcke]

Am Montag, den 13.04.2009, 16:49 +0200 schrieb Robert Millan:

Thanks for reviewing.

> On Mon, Apr 13, 2009 at 04:26:19PM +0200, Felix Zielcke wrote:
> > +#ifdef __FreeBSD_kernel__
> 
> Unfortunately FreeBSD doesn't define __FreeBSD_kernel__, so we need
> to check for both macros.

Oh right.

> > +#if defined __FreeBSD_kernel__
> > +  int sysctl_flags, sysctl_oldflags;
> > +  size_t sysctl_size = sizeof (sysctl_flags);
> 
> You can add a `const' on this one.
> 
> > +  sysctl_flags = sysctl_oldflags |= 0x10;
> 
> Shouldn't this be "sysctl_oldflags | 0x10" ?

Yes.
> Btw you can avoid the two subsequent calls if sysctl_flags == sysctl_oldflags.

Right and actually it can be even avoided if 0x10 is already set.

Is it correct that I used now `[__FreeBSD__]: Likewise.' in the
Changelog?
The GCS unfortunately doestn't tell anything about the case that a
change applies to 2 or more marcros and I couldn't find an example in
the existing Changelog for this.

-- 
Felix Zielcke
2009-04-13  Felix Zielcke  

util/hostdisk.c [__FreeBSD_kernel]: Include  and
.
[__FreeBSD__]: Likewise.
(open_device) [__FreeBSD_kernel_]: Use sysctlgetbyname() to add 0x10 to
`kern.geom.debugflags' if it's not already set, before opening the
device and reset them afterwards.
[__FreeBSD__]: Likewise.

Index: util/hostdisk.c
===
--- util/hostdisk.c (revision 2094)
+++ util/hostdisk.c (working copy)
@@ -88,6 +88,8 @@ struct hd_geometry
 
 #if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 # include  /* DIOCGMEDIASIZE */
+# include 
+# include 
 #endif
 
 struct
@@ -340,7 +342,24 @@ open_device (const grub_disk_t disk, gru
   sector -= disk->partition->start;
   }
 #else /* ! __linux__ */
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
+  int sysctl_flags, sysctl_oldflags;
+  const size_t sysctl_size = sizeof (sysctl_flags);
+
+  if (sysctlbyname ("kern.geom.debugflags", &sysctl_oldflags, &sysctl_size, 
NULL, 0))
+grub_util_error ("cannot get current flags of sysctl 
kern.geom.debugflags");
+  sysctl_flags = sysctl_oldflags | 0x10;
+  if (! sysctl_oldflags & 0x10 && sysctlbyname ("kern.geom.debugflags", NULL , 
0, &sysctl_flags, sysctl_size))
+grub_util_error ("cannot set flags of sysctl kern.geom.debugflags");
+#endif
+
   fd = open (map[disk->id].device, flags);
+
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
+  if (! sysctl_oldflags & 0x10 && sysctlbyname ("kern.geom.debugflags", NULL , 
0, &sysctl_oldflags, sysctl_size))
+grub_util_error ("cannot set flags back to the old value for sysctl 
kern.geom.debugflags");
+#endif
+
   if (fd < 0)
 {
   grub_error (GRUB_ERR_BAD_DEVICE, "cannot open `%s' in open_device()", 
map[disk->id].device);
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Video mode fixes in linux loader

[Pavel Roskin]

On Mon, 2009-04-13 at 16:45 +0200, Robert Millan wrote:
> On Mon, Apr 13, 2009 at 04:16:57PM +0200, Robert Millan wrote:
> > > The default VGA mode is now GRUB_LINUX_VID_MODE_NORMAL, not the mode of
> > > the kernel we tried to load before.
> > 
> > Ok, BUT if we're already in vesa mode, and we know it works (since we're 
> > using
> > it), there's no point in wasting time only to get a worse mode.
> > 
> > We should just make sure subsequent calls to "linux" command override the
> > previous one.
> 
> I think this should do it.  Can you confirm this works for you?

I actually installed GRUB with gfxterm on a laptop that has Intel
framebuffer support.  Now the kernel starts in VESA mode and then the
screen goes blank because intelfb cannot deal with it.  Sure, intelfb
should be fixed, but we should be liberal in what we accept.  Some
kernels may not support VESA modes at all.

Adding vga=0 to the kernel command line didn't fix it.  That's bad.
"vga=0" means text mode 80x25.  Adding "vga=1" fixed the problem.  The
text mode was 80x25, not 80x50, so that's another issue.

"vga=ask" is not a warning now.  It causes "error: You need to load the
kernel first", apparently from initrd.  In other words, the "linux"
command fails and there is no visible warning.

-- 
Regards,
Pavel Roskin


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

Re: [PATCH] Video mode fixes in linux loader

[Robert Millan]

On Mon, Apr 13, 2009 at 11:16:46AM -0400, Pavel Roskin wrote:
> On Mon, 2009-04-13 at 16:16 +0200, Robert Millan wrote:
> > Please, in general, when you modify code that has been actively worked on
> > by someone, try to get that person involved.
> 
> I tried, but probably not hard enough.  Sorry.

No problem :-)

> > Ok, BUT if we're already in vesa mode, and we know it works (since we're 
> > using
> > it), there's no point in wasting time only to get a worse mode.
> 
> Maybe we should introduce another macro, e.g.
> GRUB_LINUX_VID_MODE_CURRENT, recognize it in the loader and default to
> it.

If we're going to get creative and add new options that weren't present in
the legacy interface, then I'd really prefer if we design a new one, and
better a kernel-independant one like an env variable (we discussed this in
another thread, but didn't agree on which name to use yet).

> Yes, failed loading of one kernel should not affect loading of another
> kernel.  That was the most annoying bug, and I hope it's fixed now.

Yeah I don't see anything wrong with this situation now, but I could be
missing something, since there are many ways to "fail".

> > > Finally, "vga=ask" is now recognized.
> > 
> > With the new loader, Linux' 16-bit entry code is no longer responsible for
> > setting vesa modes, therefore vga=ask can't work.  There's no point in
> > recognizing it (except to warn the user).
> 
> I agree.  Generally, "vga=random_string" causes an error now.  Perhaps
> any unrecognized values of "vga" should cause a warning, not an error.

Probably better when it comes to headless machines, yes...

-- 
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] Video mode fixes in linux loader

[Robert Millan]

On Mon, Apr 13, 2009 at 11:41:36AM -0400, Pavel Roskin wrote:
> I actually installed GRUB with gfxterm on a laptop that has Intel
> framebuffer support.  Now the kernel starts in VESA mode and then the
> screen goes blank because intelfb cannot deal with it.  Sure, intelfb
> should be fixed, but we should be liberal in what we accept.

We could detect this situation by checking video= parameter, and setting
text mode if intelfb is found.  But then again do we want to prevent
future versions of intelfb from gracefuly transitioning from vesa mode
without screen glitch?

> Some
> kernels may not support VESA modes at all.

I don't think this is applicable;  all modern versions of Linux include
vesa modesetting in its 16-bit entry code, and older versions are already
detected by the new loader (user is prompted to use linux16).

> Adding vga=0 to the kernel command line didn't fix it.  That's bad.
> "vga=0" means text mode 80x25.  Adding "vga=1" fixed the problem.  The
> text mode was 80x25, not 80x50, so that's another issue.

Shouldn't be hard to fix.  Do you know how to switch to 80x50 mode?

> "vga=ask" is not a warning now.  It causes "error: You need to load the
> kernel first", apparently from initrd.  In other words, the "linux"
> command fails and there is no visible warning.

Sounds like my error code is wrong, but we could turn it into a warning
like you suggested.

-- 
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] fix grub-setup on kfreebsd by adding 0x10 to the sysctl ("kern.geom.debugflags") flags

[Robert Millan]

On Mon, Apr 13, 2009 at 05:11:04PM +0200, Felix Zielcke wrote:
> > Btw you can avoid the two subsequent calls if sysctl_flags == 
> > sysctl_oldflags.
> 
> Right and actually it can be even avoided if 0x10 is already set.

It's the same thing (if and only if 0x10 was set, old and new flags will
be the same).  I'm not sure which check is cheaper, but it doesn't matter
much anyway.

> Is it correct that I used now `[__FreeBSD__]: Likewise.' in the
> Changelog?
> The GCS unfortunately doestn't tell anything about the case that a
> change applies to 2 or more marcros and I couldn't find an example in
> the existing Changelog for this.

How about [__FreeBSD__ || __FreeBSD_kernel__] ?

> +  if (sysctlbyname ("kern.geom.debugflags", &sysctl_oldflags, &sysctl_size, 
> NULL, 0))
> +grub_util_error ("cannot get current flags of sysctl 
> kern.geom.debugflags");

I'd just return grub_error instead.  Otherwise we abort the program even if
failure to read a drive is not critical (e.g. lvm.mod scannning all drives,
grub-emu, etc).

> +  if (! sysctl_oldflags & 0x10 && sysctlbyname ("kern.geom.debugflags", NULL 
> , 0, &sysctl_flags, sysctl_size))
> +grub_util_error ("cannot set flags of sysctl kern.geom.debugflags");

Just a matter of taste, I'd suggest nested ifs to make it more readable.

-- 
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: Add sparc64 Linux kernel loader support.

[David Miller]

From: phcoder 
Date: Mon, 13 Apr 2009 10:58:13 +0200

> Really nice. I have no way of testing it but if it works it means that
> sparc64 port now has real life. We could even proclaim April, the 13th
> the annual GRUB2 SPARC64 day

Not really.

None of the openfirmware path handling changes are in,
as well as the sparc64 ieee1275 installation tools.

The port is only halfway there, at best.


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

Re: [PATCH]: grub: Allow to control objcopy '-B' argument from foo.rmk files.

[David Miller]

From: Robert Millan 
Date: Mon, 13 Apr 2009 16:29:10 +0200

> On Sat, Apr 11, 2009 at 01:08:31AM -0700, David Miller wrote:
>> index 7dfb854..b4f1353 100644
>> --- a/conf/i386-pc.rmk
>> +++ b/conf/i386-pc.rmk
>> @@ -17,26 +17,31 @@ pkglib_IMAGES = boot.img diskboot.img kernel.img 
>> pxeboot.img lnxboot.img \
>>  boot_img_SOURCES = boot/i386/pc/boot.S
>>  boot_img_ASFLAGS = $(COMMON_ASFLAGS)
>>  boot_img_LDFLAGS = $(COMMON_LDFLAGS) $(TARGET_IMG_LDFLAGS) -Wl,-Ttext,7C00
>> +boot_img_IMG_FMT = binary
> 
> Wait, isn't raw format implicit in the _img_ part of the variable name?
> 
> If it was ELF, we'd have boot_elf_..., right?

We have "images" which match the foo_img_* pattern, modules,
scripts, and "everything else" which we call programs and
the foo_elf_* rules match.

Feel free to double-check my attempted interpretation of the
code in genmk.rb

Really, I am pretty sure this is the best way to handle this.


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

Re: [PATCH]: grub: Add Sun partition support to grub-probe and grub-fstest.

[David Miller]

From: Pavel Roskin 
Date: Mon, 13 Apr 2009 08:51:36 -0400

> On Sun, 2009-04-12 at 23:53 -0700, David Miller wrote:
>> Should be self-explanatory, these tools will be used on sparc64 just
>> like they are on i386-pc
> 
> Fine with me.

Thanks for reviewing, committed.


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

Re: [PATCH] FreeBSD 64-bit kernel support

[Joey Korkames]

That did the trick - amd64 boots with a mfsroot now. thanks!

-joey

phcoder writes:


Try this
Joey Korkames wrote:

phcoder writes:


Joey Korkames wrote:
Hmm, FreeBSD seems to choke when trying to load the grub-bootstrapped 
mfsroot.gz (as the root device - haven't tried loading without 
rooting from it)...



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

Re: [PATCH]: grub: Kill fixed device name length from make_device_name().

[David Miller]

From: David Miller 
Date: Sun, 12 Apr 2009 23:53:04 -0700 (PDT)

> make_device_name() uses an arbitrary value for the device name
> length, putting an arbitrary limit on such strings.
> 
> We can do better by calculating the length of this string precisely.
> 
> 2009-04-12  David S. Miller  
> 
>   * util/hostdisk.c (make_device_name): Do not make any assumptions
>   about the length of drive names.

This patch seems straightforward and no objections have been
raised, so I've commited the change.


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

Re: grub: Eliminate recursive reads of the same device in grub_dl_load_file().

[David Miller]

From: David Miller 
Date: Sun, 12 Apr 2009 23:56:11 -0700 (PDT)

> 
> Openfirmware block device drivers do not allow for multiple concurrent
> opens of the same device.  It simply does not work.
> 
> Fortunately grub doesn't actually need to do this, it just happens
> to do so.  Here is the fix for the case of module dependency handling.
> 
> The other case that hits this problem is in the FS_UUID support code.
> I have patches later which will fix that case too, but that one is a
> little more involved as we have to fix some bugs in the the ieee1275
> devalias iterator first (for one, it doesn't stop when the callback
> returns non-zero as every other iterator in grub2 does).
> 
> 2009-04-12  David S. Miller  
> 
>   * kern/dl.c (grub_dl_load_file): Close file immediately when
>   we are done using it.

I've committed this change as well.


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

Re: [PATCH] Video mode fixes in linux loader

[Pavel Roskin]

On Mon, 2009-04-13 at 21:05 +0200, Robert Millan wrote:
> On Mon, Apr 13, 2009 at 11:41:36AM -0400, Pavel Roskin wrote:
> > I actually installed GRUB with gfxterm on a laptop that has Intel
> > framebuffer support.  Now the kernel starts in VESA mode and then the
> > screen goes blank because intelfb cannot deal with it.  Sure, intelfb
> > should be fixed, but we should be liberal in what we accept.
> 
> We could detect this situation by checking video= parameter, and setting
> text mode if intelfb is found.  But then again do we want to prevent
> future versions of intelfb from gracefuly transitioning from vesa mode
> without screen glitch?

No, that would be bad.  It's even possible that intelfb would work
correctly in other configurations.  The laptop has resolution 1440x900
that doesn't match any VESA mode.

> > Some
> > kernels may not support VESA modes at all.
> 
> I don't think this is applicable;  all modern versions of Linux include
> vesa modesetting in its 16-bit entry code, and older versions are already
> detected by the new loader (user is prompted to use linux16).

I can disable CONFIG_FB, and then the screen remains blank until X
starts.  It's entirely possible that some distros don't enable CONFIG_FB
to save memory, and I don't always enable it in the kernels I configure
myself.

> > Adding vga=0 to the kernel command line didn't fix it.  That's bad.
> > "vga=0" means text mode 80x25.  Adding "vga=1" fixed the problem.  The
> > text mode was 80x25, not 80x50, so that's another issue.
> 
> Shouldn't be hard to fix.  Do you know how to switch to 80x50 mode?

Well, load 8x8 font.  It's done in the 16-bit code.

> > "vga=ask" is not a warning now.  It causes "error: You need to load the
> > kernel first", apparently from initrd.  In other words, the "linux"
> > command fails and there is no visible warning.
> 
> Sounds like my error code is wrong, but we could turn it into a warning
> like you suggested.

I was editing the command line from the menu, so I  could not see the
message.  Waiting for input is a fair game for an option that implies
waiting for input.

-- 
Regards,
Pavel Roskin


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

Re: [PATCH] Video mode fixes in linux loader

[phcoder]

Pavel Roskin wrote:

On Mon, 2009-04-13 at 21:05 +0200, Robert Millan wrote:

On Mon, Apr 13, 2009 at 11:41:36AM -0400, Pavel Roskin wrote:

I actually installed GRUB with gfxterm on a laptop that has Intel
framebuffer support.  Now the kernel starts in VESA mode and then the
screen goes blank because intelfb cannot deal with it.  Sure, intelfb
should be fixed, but we should be liberal in what we accept.

We could detect this situation by checking video= parameter, and setting
text mode if intelfb is found.  But then again do we want to prevent
future versions of intelfb from gracefuly transitioning from vesa mode
without screen glitch?


No, that would be bad.  It's even possible that intelfb would work
correctly in other configurations.  The laptop has resolution 1440x900
that doesn't match any VESA mode.

With proposed autodetections bootloader becomes overzealous. I think it 
should be configirable but in a more modern way. I think gfxpayload with 
the same syntax as gfxmode plus additional platform-specific keywords 
like text80x25 and text80x50 should be fine. If to gfxpayload variable 
set, then use current mode.
I object against a solution of just using current mode because of the 
current state on EFI: code to retrieve framebuffer address isn't yet 
used for gfxterm. If this is fixed then I could agree with "last mode" 
solution.


vga= option could be deleted altogether and replaced by warning if 
someone passes it. If we do so it's better to do before debian switches


--

Regards
Vladimir 'phcoder' Serbinenko


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

status grub2 port of grub-legasy map command

[John Stanley]

Hi all,
I was wondering what the current status of a grub2 port of the grub-0.97 
"map" and "rootnoverify" commands is?  I have found some work done to 
this end in the "drivemap.patch" work, but I find nothing more recent 
than drivemap.patch.8 dated around Aug 2008.


I have taken drivemap.patch.8 and made a few updates so that it builds 
and works, at least partially, in grub2-r2101. I build "homebrew" linux 
systems for my laptops (thinkpads) and desktops and on several of them I 
have a 2nd hd installed in the cd-bay with Windows XP. For dual booting, 
I've been using grub legasy w/o problems using:


title   Windows XP
   rootnoverify (hd1,0)
   map (hd1) (hd0)
   map (hd0) (hd1)
   chainloader +1

For grub2-r2101, I use:

### BEGIN /etc/grub.d/40_custom ###
# This file is an example on how to add custom entries
menuentry "Microsoft Windows XP" {
  drivemap (hd0) (hd1)
  set root=(hd1,1)
  chainloader --force +1
}

When I use drivemap as above, on booting Windows I get the message:

unaligned pointer 0x76697264
Aborted. Press any key to exit

I then simply hit "enter," and Windows begins to boot. So, the mapping 
works, I do have dual-booting with Windows not on the (bios) first 
drive,  but mm.c complains about an unaligned pointer.


Could anyone give me any pointers/direction on what might be happening 
here? Could it be that the "norootverify"-functionality of grub-legasy 
is lacking here? Or, perhaps, that the "--force" option is not being 
honored ?


Any help/suggestions/related-info would be greatly appreciated.

Thus far, I have not been able to get a Windows boot using the "-s" 
switch of drivemap , e.g., "drivemap -s (hd0) (hd1)" as this results in 
a grub Abort, followed by a reboot.


John


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

grub-fstest build issue in grub2-r2071 +

[John Stanley]

Hi all,

I have built grub2-r2065 and it works nicely for me so far for linux 
boots (love the graphics!!). However, beginning with r2071, I am unable 
to build it with the "--enable-grub-fstest" option  due to several 
undefined refs:
# 
- 


# Fix grub_fstest-normal_misc.o unresolve ref error:
#   In function `grub_normal_print_device_info':
#   /build/grub2-r2077-jps_src/grub2-r2077/normal/misc.c:74: undefined 
reference to `grub_unixtime2datetime'
#   /build/grub2-r2077-jps_src/grub2-r2077/normal/misc.c:75: undefined 
reference to `grub_get_weekday_name'

#   grub_fstest-commands_ls.o: In function `print_files_long':
#   /build/grub2-r2077-jps_src/grub2-r2077/commands/ls.c:149: undefined 
reference to `grub_unixtime2datetime'
#   /build/grub2-r2077-jps_src/grub2-r2077/commands/ls.c:151: undefined 
reference to `grub_get_weekday_name'

#   collect2: ld returned 1 exit status
#   make: *** [grub-fstest] Error 1
# 
-- 

# conf/common.rmk is used by configure to generate conf/common.mk, so 
modify the former.


To handle this (I'm now building r2101), I add normal/datetime to the 
grub-fstest build specs,

as follows:

# 
- 


# Only add normal/datetime.c if not present:
sed '/grub-fstest.c_DEPENDENCIES/,/For /{s:normal/datetime.c:jps:}' \
  conf/common.rmk |grep -q jps ||
sed -i 's:^grub_fstest_SOURCES =:& normal/datetime.c:' conf/common.rmk
# 
-- 



Has anyone come across this ? Actually, I'm not even sure what fstest is 
used for, so I could simply remove the option when I do configure...


John


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

Re: grub-fstest build issue in grub2-r2071 +

[Pavel Roskin]

On Mon, 2009-04-13 at 21:06 -0400, John Stanley wrote:
> Hi all,
> 
> I have built grub2-r2065 and it works nicely for me so far for linux 
> boots (love the graphics!!). However, beginning with r2071, I am unable 
> to build it with the "--enable-grub-fstest" option  due to several 
> undefined refs:

It started in r2067.

> To handle this (I'm now building r2101), I add normal/datetime to the 
> grub-fstest build specs,

Fixed in subversion.  Thank you!

-- 
Regards,
Pavel Roskin


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

Re: grub-fstest build issue in grub2-r2071 +

[John Stanley]

Hi Again,
Thanks, r2104 builds with --enable-grub-fstest now, but a new problem, 
not present in r2101 has surfaced: the command grub-probe now aborts on 
my system with xfs filesystems. Therefore, I cannot run grub-install 
(even  with  --modules=xfs). With rev's 2101, 2087, 2077, 2071, and 2065 
grub-probe ran without error. Here's my hd config:


#device mount-point fs type options dumpfsck
/dev/hda1   swapswapdefaults0   0
/dev/hda2   /   xfs defaults1   1


and here's the output of grub-probe (r2104):

# grub-probe -v --target=fs --device /dev/hda2
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd1 is 156301488
grub-probe: info: the size of hd1 is 156301488
grub-probe: info: the size of hd1 is 156301488
grub-probe: info: the size of hd1 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd0 is 156301488
grub-probe: info: the size of hd1 is 156301488
grub-probe: info: the size of hd1 is 156301488
grub-probe: info: the size of hd1 is 156301488
grub-probe: info: the size of hd1 is 156301488
grub-probe: info: /dev/hda2 starts from 2056320
grub-probe: info: opening the device hd0
grub-probe: info: the size of hd0 is 156301488
Aborted

thanks again,
John


Pavel Roskin wrote:

On Mon, 2009-04-13 at 21:06 -0400, John Stanley wrote:
  

Hi all,

I have built grub2-r2065 and it works nicely for me so far for linux 
boots (love the graphics!!). However, beginning with r2071, I am unable 
to build it with the "--enable-grub-fstest" option  due to several 
undefined refs:



It started in r2067.

  
To handle this (I'm now building r2101), I add normal/datetime to the 
grub-fstest build specs,



Fixed in subversion.  Thank you!

  



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