Re: [PATCH] remove target_os
Javier Martín wrote: A, say, AMD64 Linux cross compiler hosted on x86 Cygwin would have $build=i686-pc-cygwin and $host=amd64-linux-gnu. Thus, no conflict ought to arise even with cross compilation enabled. AFAIK, the full power of $build+$host+$target only matters when building _compilers_ (and binutils, etc.), because you might want to use an AMD64/Linux machine to build a compiler that will run on PPC/Darwin but produce executables for a x86/Cygwin machine Now lets move this idea to GRUB 2: There is a build server is running on PPC/Linux and it wants to build all architectures supported by GRUB 2 (provide proper boot code for all arch and tools) and then makes software bundles (rpm,deb, or so) for all architectures. In example if all shell tools are to be ran on x86-64/Linux and then boot code needs to be compatible with x86-32 as there is PC-BIOS present on target system. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: State of GRUB on PowerPC
Michel Dänzer wrote: P.S. Please reconsider automatically rejecting posts from non-subscribers. I co-moderate half a dozen mailing lists, only costs me a couple of minutes a day thanks to a nice tool called 'listadmin'. grub-devel is a subscriber only list. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] remove target_os
Javier Martín wrote:
Unfortunately, gcc has no '-fno_os' option to specify the bare CPU as
target.
Might -ffreestanding be what you are looking for?
The option '-ffreestanding' is the same as '-fno-hosted'.
According to gcc (4.3.1) source, '-fno-hosted' clears variable
'flag_hosted' and sets '-fno-builtin'. The latter is already set within
GRUB build.
A cleared 'flag_hosted' apparently has only 2 effects:
- disable the special handling of 'main()'.
- #define __STDC_HOSTED__ to 0 instead of 1
There is no effect on the target_os dependent parts of the gcc code
generation. For example, on i386, __enable_execute_stack() calls are
generated for target_os netbsd, openbsd and cygwin, but not for linux.
The emit call is hard-coded in
gcc/configs/i386/i386.c:x86_initialize_trampoline().
Other workarounds are needed to support building GRUB with code
generators tailored for various target_os.
AC_MSG_CHECKING([for command to convert module to ELF format])
-case ${host_os}:${target_os} in
- cygwin:cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
+case ${host_os} in
+ cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
*) ;;
esac
This won't work for a Linux cross compiler hosted on Cygwin. It would
emit ELF format and does not need pe2elf.
A, say, AMD64 Linux cross compiler hosted on x86 Cygwin would have
$build=i686-pc-cygwin and $host=amd64-linux-gnu. Thus, no conflict ought
to arise even with cross compilation enabled.
But the opposite won't work: $host=i686-pc-cygwin would enable
grub-pe2elf, even if this gcc emits ELF for a linux target.
Christian
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] remove target_os
El mar, 27-01-2009 a las 18:51 +0200, Vesa Jääskeläinen escribió: Javier Martín wrote: A, say, AMD64 Linux cross compiler hosted on x86 Cygwin would have $build=i686-pc-cygwin and $host=amd64-linux-gnu. Thus, no conflict ought to arise even with cross compilation enabled. AFAIK, the full power of $build+$host+$target only matters when building _compilers_ (and binutils, etc.), because you might want to use an AMD64/Linux machine to build a compiler that will run on PPC/Darwin but produce executables for a x86/Cygwin machine Now lets move this idea to GRUB 2: There is a build server is running on PPC/Linux and it wants to build all architectures supported by GRUB 2 (provide proper boot code for all arch and tools) and then makes software bundles (rpm,deb, or so) for all architectures. In example if all shell tools are to be ran on x86-64/Linux and then boot code needs to be compatible with x86-32 as there is PC-BIOS present on target system. So you propose --target to be reused like this (a PS3 building GRUB2 for an amd64 BIOS PC with Linux) : ./configure --build=ppc64-linux --host=x86_64-linux-gnu --target=i686-pc ^--compiling system ^--tools system ^--boot arch I think we already have a better-geared switch for that (--with-platform it is?), which is currently used to distinguish between BIOS and EFI boot code on both x86 and x86-64. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel signature.asc Description: Esta parte del mensaje está firmada digitalmente ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] remove target_os
El mar, 27-01-2009 a las 18:21 +0100, Christian Franke escribió:
Javier Martín wrote:
Unfortunately, gcc has no '-fno_os' option to specify the bare CPU as
target.
Might -ffreestanding be what you are looking for?
The option '-ffreestanding' is the same as '-fno-hosted'.
According to gcc (4.3.1) source, '-fno-hosted' clears variable
'flag_hosted' and sets '-fno-builtin'. The latter is already set within
GRUB build.
A cleared 'flag_hosted' apparently has only 2 effects:
- disable the special handling of 'main()'.
- #define __STDC_HOSTED__ to 0 instead of 1
There is no effect on the target_os dependent parts of the gcc code
generation. For example, on i386, __enable_execute_stack() calls are
generated for target_os netbsd, openbsd and cygwin, but not for linux.
The emit call is hard-coded in
gcc/configs/i386/i386.c:x86_initialize_trampoline().
In that case, we are dealing with a GCC bug. We might want to require
the user to create a bare no-OS cross compiler. These thingies are
most likely only known to OS developers, but you can build a perfectly
good i686-pc-elf GCC (only with no libc, of course). This might be the
Right Way (TM) of building boot code, instead of the current way of
using the OS-targetter compiler and trying to tell it not to do what it
was built to do.
Other workarounds are needed to support building GRUB with code
generators tailored for various target_os.
AC_MSG_CHECKING([for command to convert module to ELF format])
-case ${host_os}:${target_os} in
- cygwin:cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
+case ${host_os} in
+ cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
*) ;;
esac
This won't work for a Linux cross compiler hosted on Cygwin. It would
emit ELF format and does not need pe2elf.
A, say, AMD64 Linux cross compiler hosted on x86 Cygwin would have
$build=i686-pc-cygwin and $host=amd64-linux-gnu. Thus, no conflict ought
to arise even with cross compilation enabled.
But the opposite won't work: $host=i686-pc-cygwin would enable
grub-pe2elf, even if this gcc emits ELF for a linux target.
The opposite of a the described situation would be a Linux AMD64
machine cross compiling for a Cygwin x86 machine, that is
$build=amd64-linux-gnu and $host=i686-pc-cygwin. In that case,
i686-pc-cygwin-gcc would generate PE executables, and thus grub-pe2elf
_is_ required indeed.
Christian
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] remove target_os
Javier Martín wrote:
El mar, 27-01-2009 a las 18:21 +0100, Christian Franke escribió:
Javier Martín wrote:
Unfortunately, gcc has no '-fno_os' option to specify the bare CPU as
target.
Might -ffreestanding be what you are looking for?
The option '-ffreestanding' is the same as '-fno-hosted'.
According to gcc (4.3.1) source, '-fno-hosted' clears variable
'flag_hosted' and sets '-fno-builtin'. The latter is already set within
GRUB build.
A cleared 'flag_hosted' apparently has only 2 effects:
- disable the special handling of 'main()'.
- #define __STDC_HOSTED__ to 0 instead of 1
There is no effect on the target_os dependent parts of the gcc code
generation. For example, on i386, __enable_execute_stack() calls are
generated for target_os netbsd, openbsd and cygwin, but not for linux.
The emit call is hard-coded in
gcc/configs/i386/i386.c:x86_initialize_trampoline().
In that case, we are dealing with a GCC bug. We might want to require
the user to create a bare no-OS cross compiler.
Is building a bare 'no-OS' compiler supported by the upstream GCC sources?
Probably a too strict prerequisite for building GRUB.
AC_MSG_CHECKING([for command to convert module to ELF format])
-case ${host_os}:${target_os} in
- cygwin:cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
+case ${host_os} in
+ cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
*) ;;
esac
This won't work for a Linux cross compiler hosted on Cygwin. It would
emit ELF format and does not need pe2elf.
A, say, AMD64 Linux cross compiler hosted on x86 Cygwin would have
$build=i686-pc-cygwin and $host=amd64-linux-gnu. Thus, no conflict ought
to arise even with cross compilation enabled.
But the opposite won't work: $host=i686-pc-cygwin would enable
grub-pe2elf, even if this gcc emits ELF for a linux target.
The opposite of a the described situation would be a Linux AMD64
machine cross compiling for a Cygwin x86 machine, that is
$build=amd64-linux-gnu and $host=i686-pc-cygwin. In that case,
i686-pc-cygwin-gcc would generate PE executables, and thus grub-pe2elf
_is_ required indeed.
Yes - I was wrong, sorry.
Robert: Patch is IMO GTG.
Christian
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
GRUB 2 for DEC Alpha?
Hi, I learned today that GRUB 2 aims to be cross platform and already supports in some form PPC. Is there any interest in supporting the DEC Alpha (SRM) platform? According to the Current Status [*] page, BSD partition maps are already supported, so maybe the only thing to be done is the SRM-specific code? Alpha users currently use the long unmaintained aboot bootloader. Possibly code could be reused from aboot. Thanks, Matt Turner [*] http://grub.enbug.org/CurrentStatus ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB 2 for DEC Alpha?
Matt Turner wrote: Hi, I learned today that GRUB 2 aims to be cross platform and already supports in some form PPC. Is there any interest in supporting the DEC Alpha (SRM) platform? If you are planning to provide the code for it and maintain it :) (or someone else). Alpha users currently use the long unmaintained aboot bootloader. Possibly code could be reused from aboot. We are using GPL v3. And that is not joy either to copy code... ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bugfix: no cursor on command line
phcoder wrote:
Testing grub I noticed this bug. Here is bugfix
Vladimir 'phcoder' Serbinenko
Index: normal/cmdline.c
===
--- normal/cmdline.c(revision 1959)
+++ normal/cmdline.c(working copy)
@@ -148,6 +148,7 @@
{
static char cmdline[GRUB_MAX_CMDLINE];
+ grub_setcursor (1);
grub_print_error ();
grub_errno = GRUB_ERR_NONE;
cmdline[0] = '\0';
I do not remember seeing a problem here. So what is actually the problem
and how to reproduce it?
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bugfix: no cursor on command line
I do not remember seeing a problem here. So what is actually the problem and how to reproduce it? I booted GRUB2 by GRUB-Legacy, command prompt appeared and worked but there were no cursor. I think the same problem appears when the user opens command line from the menu. Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bugfix: no cursor on command line
phcoder wrote: I do not remember seeing a problem here. So what is actually the problem and how to reproduce it? I booted GRUB2 by GRUB-Legacy, command prompt appeared and worked but there were no cursor. I think the same problem appears when the user opens command line from the menu. Still not seeing this. There is already a call to grub_setcursor (1) at the beginning of this function... (and that was added somewhere in 2005)... I tried both graphical and text console and none seem to be affected. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Grub 2 command : uppermem (patch proposal)
Hello List, I was going through the Grub 2 TODO here : http://grub.enbug.org/TodoList and I see that one of the many commands that need to be implemented is uppermem. Having played around with uppermem quite a bit (thanks to the weird systems I have to work with) on Grub Legacy, I was wondering if a patch for the same would be considered for inclusion? Please note that I haven't started work on it yet. I wanted to make sure that it's something desirable before putting up a patch. Thanks, Bandan -- BSD ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] caseless uuid detection, fixed wrong behaviour for strncasecmp, added strcasecmp
On Mon, 2009-01-26 at 19:28 +0100, Daniel Mierswa wrote: On 26.01.2009 05:41, Pavel Roskin wrote: I'll appreciate if you write your Changelog entries according to the GNU coding standards. In particular, please don't abbreviate function names. Ok, second try. I should have told you that I had applied your patch with rewritten ChangeLog entries. A quick look at your second try shows that you didn't check the GNU coding standards. You can find it using Google or another search engine. The part dealing with ChangeLogs is here: http://www.gnu.org/prep/standards/standards.html#Change-Logs We have a very similar function search_fs_uuid() in disk/fs_uuid.c, and it still uses grub_strcmp(). Should it be using grub_strcasecmp() as well? Can we export that function to reuse it in commands/search.c? Yes it should use grub_strcasecmp, thanks for noticing. I don't know exactly if we can reuse that function at another place. I leave that to someone who knows where this code is executed. :-) The code is executed when the disk is referenced by its UUID. OK, I'll take care of it. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] caseless uuid detection, fixed wrong behaviour for strncasecmp, added strcasecmp
On Tue, 2009-01-27 at 20:49 -0500, Pavel Roskin wrote: We have a very similar function search_fs_uuid() in disk/fs_uuid.c, and it still uses grub_strcmp(). Should it be using grub_strcasecmp() as well? Can we export that function to reuse it in commands/search.c? P.S. The reuse would be impractical. fs_uuid is a separate module, not the core. Reusing search_fs_uuid() would make the search module depend on fs_uuid. In my opinion, it's not worth the trouble to introduce that dependency. It's not like we would save a lot of code. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bugfix: no cursor on command line
Sorry it seems that my fs was corrupted which caused failure at install. fsck and reinstall fixed the problem Thanks Vladimir 'phcoder' Serbinenko Vesa Jääskeläinen wrote: phcoder wrote: I do not remember seeing a problem here. So what is actually the problem and how to reproduce it? I booted GRUB2 by GRUB-Legacy, command prompt appeared and worked but there were no cursor. I think the same problem appears when the user opens command line from the menu. Still not seeing this. There is already a call to grub_setcursor (1) at the beginning of this function... (and that was added somewhere in 2005)... I tried both graphical and text console and none seem to be affected. ___ 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
xnu support
Hello, I'm working on xnu (darwin kernel, under OSI approved APSL)
support and would like to discuss some interfaces about it.
Issue 1) First in xnu world booter hands the loading of compressed
hibernation image. Resuming doesn't need to load the kernel conventional
way. And trying to resume from hibernate should be done before trying to
load kernel. So I propose the following configuration entries:
menuentry my XNU
{
if ! xnu_resume hibernate image; then
xnu_kernel kernel options
xnu_extensions --cache=cache file --dir=cache directory
xnu_loadenv environment description file
fi
}
Issue 2) Also normally when hibernation succeeds kernel should
invalidate the image. Unfortunately in some scenarios it doesn't. A
reliable way to check the image is to compare modification timestamp of
FS and image.
I know where to find them on FS but unfortunately now grub has no way of
interfacing this with FS code. I propose to modify
/* Call HOOK with each file under DIR. */
grub_err_t (*dir) (grub_device_t device, const char *path,
int (*hook) (const char *filename, int dir));
to
/* Call HOOK with each file under DIR. */
grub_err_t (*dir) (grub_device_t device, const char *path,
int (*hook) (const char *filename, int dir,
grub_time_t modtime));
Or add
grub_err_t (*file_modtime) (const char *name, grub_time_t *modtime);
and add a function for retrieving FS modification type
grub_err_t (*fs_modtime) (grub_device_t device, grub_time_t *modtime);
to grub_fs_t
This has an additional benefit of invalidating image if FS was modified
by external tool. This may be overriden by --force option to override it.
File modification timestamp are also needed to check if the extension
cache is up to date.
Issue 3) Kernel may theoretically request loading parts to any address.
In practice it does it only in 1Mb-64Mb range. Is it possible to somehow
secure this range from grub_malloc after xnu_kernel command? (I would
like to avoid just before boot relocations if possible)
I send an implementation of xnu_resume. Not for inclusion of course but
for illustration
Thanks
Any opinion is appreciated
Vladimir 'phcoder' Serbinenko
Index: conf/i386.rmk
===
--- conf/i386.rmk (revision 1962)
+++ conf/i386.rmk (working copy)
@@ -14,3 +14,8 @@
vga_text_mod_SOURCES = term/i386/pc/vga_text.c term/i386/vga_common.c
vga_text_mod_CFLAGS = $(COMMON_CFLAGS)
vga_text_mod_LDFLAGS = $(COMMON_LDFLAGS)
+
+pkglib_MODULES += xnu.mod
+xnu_mod_SOURCES = loader/xnu_resume.c loader/i386/xnu.c
+xnu_mod_CFLAGS = $(COMMON_CFLAGS)
+xnu_mod_LDFLAGS = $(COMMON_LDFLAGS)
Index: include/grub/i386/xnu.h
===
--- include/grub/i386/xnu.h (revision 0)
+++ include/grub/i386/xnu.h (revision 0)
@@ -0,0 +1,9 @@
+#define XNU_MEMORY_START 0x10
+#define XNU_MEMORY_END 0x400
+#define XNU_PAGESIZE 4096
+
+grub_err_t grub_xnu_boot (void);
+extern void *grub_xnu_entry_point;
+extern void *grub_xnu_stack;
+extern void *grub_xnu_arg1;
+
Index: include/grub/xnu.h
===
--- include/grub/xnu.h (revision 0)
+++ include/grub/xnu.h (revision 0)
@@ -0,0 +1,18 @@
+#define XNU_HIBERNATE_MAGIC 0x73696d65
+struct xnu_hibernate_header
+{
+ grub_uint64_t image_size;
+ grub_uint8_t unknown1[8];
+ grub_uint32_t restorepage;
+ grub_uint32_t numofpages;
+ grub_uint32_t entry_point;
+ grub_uint32_t stack;
+ grub_uint8_t unknown2[20];
+ grub_uint32_t restored_checksum;
+ grub_uint8_t unknown3[20];
+ grub_uint32_t magic;
+ grub_uint8_t unknown4[28];
+ grub_uint64_t encoffset;
+ grub_uint8_t unknown5[360];
+ grub_uint32_t extmapsize;
+} __attribute__ ((packed));
Index: loader/i386/xnu.c
===
--- loader/i386/xnu.c (revision 0)
+++ loader/i386/xnu.c (revision 0)
@@ -0,0 +1,27 @@
+#include grub/normal.h
+#include grub/dl.h
+#include grub/arg.h
+#include grub/file.h
+#include grub/disk.h
+#include grub/misc.h
+#include grub/xnu.h
+#include grub/cpu/xnu.h
+#include grub/mm.h
+#include grub/loader.h
+#include grub/cpu/loader.h
+
+/* Registers on XNU boot: eip,esp and eax*/
+void *grub_xnu_entry_point=0;
+void *grub_xnu_stack=0;
+void *grub_xnu_arg1=0;
+
+grub_err_t
+grub_xnu_boot (void)
+{
+ /*Setup regs and launch xnu*/
+ asm volatile (movl %0, %%eax : : m (grub_xnu_arg1));
+ asm volatile (movl %0, %%ebx : : m (grub_xnu_stack));
+ asm volatile (movl %0, %%ecx : : m (grub_xnu_entry_point));
+ asm volatile (movl %%ebx, %%esp : : );
+ asm volatile (jmp *%%ecx : : );
+}
Index: loader/xnu_resume.c
===
--- loader/xnu_resume.c (revision 0)
+++ loader/xnu_resume.c (revision 0)
@@ -0,0 +1,141 @@
+#include grub/normal.h
+#include grub/dl.h
+#include grub/arg.h
+#include grub/file.h
