Quoting Hollis Blanchard <[EMAIL PROTECTED]>:
> On Thu, 2006-09-28 at 15:45 +0200, [EMAIL PROTECTED] wrote:
> >
> > if (grub_strcmp (name, "grub_mod_init") == 0)
> > mod->init = (void (*) (grub_dl_t)) sym->st_value;
> >
> > This won't work on ia64 AFAIK.
>
> Can't this proble
On Thu, 2006-09-28 at 15:45 +0200, [EMAIL PROTECTED] wrote:
>
> if (grub_strcmp (name, "grub_mod_init") == 0)
> mod->init = (void (*) (grub_dl_t)) sym->st_value;
>
> This won't work on ia64 AFAIK.
Can't this problem be solved with an architecture-specific macro?
FWIW, 64-b
Quoting Marco Gerards <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] writes:
>
> >> Can you please explain why you want this in detail? I know there are
> >> issues with EFI to determine the prefix. My guess is that is why you
> >> want to change this.
> > Yes.
>
> Please elaborate.
The prefix is dete
On Tue, Sep 26, 2006 at 08:29:33PM +0300, Vesa Jääskeläinen wrote:
> Hi,
>
> Here are some comments about your patch. As requested :)
Thanks for the corrections. Some of them make me ashamed, I should have
looked better at all those grub-probefs instances... ;)
> Robert Millan wrote:
> > 2006-0
Anthony Green <[EMAIL PROTECTED]> writes:
> On Thu, 2006-09-28 at 16:31 +0200, Marco Gerards wrote:
>> Anthony Green <[EMAIL PROTECTED]> writes:
>>
>> Hi,
>>
>> > I'm just curious... are there any plans for resumo[1]-like
>> > functionality in grub2?
>>
>> Isn't this just the same as the fall
On Thu, 2006-09-28 at 16:31 +0200, Marco Gerards wrote:
> Anthony Green <[EMAIL PROTECTED]> writes:
>
> Hi,
>
> > I'm just curious... are there any plans for resumo[1]-like
> > functionality in grub2?
>
> Isn't this just the same as the fallback option in GRUB Legacy?
Looks like it. Thanks f
Anthony Green <[EMAIL PROTECTED]> writes:
Hi,
> I'm just curious... are there any plans for resumo[1]-like
> functionality in grub2?
Isn't this just the same as the fallback option in GRUB Legacy?
--
Marco
___
Grub-devel mailing list
Grub-devel@g
[EMAIL PROTECTED] writes:
>> Can you please explain why you want this in detail? I know there are
>> issues with EFI to determine the prefix. My guess is that is why you
>> want to change this.
> Yes.
Please elaborate.
>> But I am afraid this might not be a generic
>> solution so I hope we ca
Hi there,
I'm just curious... are there any plans for resumo[1]-like
functionality in grub2?
Thanks,
AG
[1] http://resumo.sourceforge.net/
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Hi,
this patch is extracted from my previous ia64 patches.
Tristan.
2006-09-28 Tristan Gingold <[EMAIL PROTECTED]>
* kern/misc.c (grub_strtoull): guess the base only if not specified.
--- grub2.cvs/kern/misc.c 2006-06-04 17:56:54.0 +0200
+++ grub2/kern/misc.c 2006-09-
Johan Rydberg <[EMAIL PROTECTED]> writes:
> Marco Gerards <[EMAIL PROTECTED]> writes:
>
>>> + memory_map = grub_efi_allocate_pages
>>> +(0, 2 * BYTES_TO_PAGES (memory_map_size + 0x1000));
>>>
>>> I suppose you add 0x1000 to round it up. Maybe we should change
>>> the BYTES_TO_PAGES macro to
Marco Gerards <[EMAIL PROTECTED]> writes:
>> + memory_map = grub_efi_allocate_pages
>> +(0, 2 * BYTES_TO_PAGES (memory_map_size + 0x1000));
>>
>> I suppose you add 0x1000 to round it up. Maybe we should change
>> the BYTES_TO_PAGES macro to do roundup.
>
> Agreed. Can you make this change a
[EMAIL PROTECTED] writes:
>> It is not possible to find similar integer division code in glibc for
>> example? And why is this code needed at all, doesn't IA64 have
>> division?
> No, it doesn't have integer division.
>
>> If it doesn't, my gut feeling tells me that this should be
>> in libgcc.
Quoting Marco Gerards <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] writes:
>
> Hi,
>
> > this is a port of grub2 to ia64. ia64 systems (itanium) are EFI based so
> this
> > port reuse existing EFI infrastructure.
>
> This is truly great, thanks a lot for doing this! :-)
>
> First of all, the same com
Johan Rydberg <[EMAIL PROTECTED]> writes:
> + memory_map = grub_efi_allocate_pages
> +(0, 2 * BYTES_TO_PAGES (memory_map_size + 0x1000));
>
> I suppose you add 0x1000 to round it up. Maybe we should change the
> BYTES_TO_PAGES macro to do roundup.
Agreed. Can you make this change as well?
[EMAIL PROTECTED] writes:
> some systems have a really big memmap. This patch remove the memmap
> size limit.
Overall the patch looks good, I have one comment through; (the patch
is for kern/efi/mm.c if someone wonders.)
+ memory_map = grub_efi_allocate_pages
+(0, 2 * BYTES_TO_PAGES (memor
袁源 <[EMAIL PROTECTED]> writes:
> recently I have been working under grub2. I wrote some of my own
> modules and I don't know how to add it to the grub2 kernel (I mean
> how to pack it to the core.img,not using the command :insmod).I
> tried to find ways through the Internet but i got none. I am v
Quoting Johan Rydberg <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] writes:
>
> > this is a port of grub2 to ia64. ia64 systems (itanium) are EFI
> > based so this port reuse existing EFI infrastructure.
>
> Thank you for offering this contribution.
You're welcome!
> First a few legal comments. I po
[EMAIL PROTECTED] writes:
> This is on an ia64 system (Tiger).
I just noticed that because of your other patches, neat! :-)
>> Cool. Can you please send in this patch in unified diff format (diff
>> -up) and provide a changelog entry? And while you on it, most people
>> here prefer patches bei
Johan Rydberg <[EMAIL PROTECTED]> writes:
> First a few legal comments. I poked through the patches, and it seems
> that there are a few files that are copyrighted by Hewlett-Packard and
> David Mosberger-Tang. All developers of GNU GRUB has agreed to sign
> over their copyright to FSF, so brini
[EMAIL PROTECTED] writes:
Hi,
> this is a port of grub2 to ia64. ia64 systems (itanium) are EFI based so this
> port reuse existing EFI infrastructure.
This is truly great, thanks a lot for doing this! :-)
First of all, the same comment as for your other emails. Please use
diff -up and inline
[EMAIL PROTECTED] writes:
> this is a port of grub2 to ia64. ia64 systems (itanium) are EFI
> based so this port reuse existing EFI infrastructure.
Thank you for offering this contribution.
First a few legal comments. I poked through the patches, and it seems
that there are a few files that ar
Quoting "bibo,mao" <[EMAIL PROTECTED]>:
> It is great!!!, I will test on my IA64 box tommorrow. And I have few minor
> comments like this.
>whether kern/ia64/efi/init.c can be common for all architectures of efi
> platform, only grub_arch_sync_caches is different, this function can be
> placed
It is great!!!, I will test on my IA64 box tommorrow. And I have few minor
comments like this.
whether kern/ia64/efi/init.c can be common for all architectures of efi
platform, only grub_arch_sync_caches is different, this function can be placed
on arch specific place. Function find_mmap_size
Quoting Marco Gerards <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] writes:
>
> Hi,
>
> First of all, thanks a lot for this patch.
>
> > some systems have a really big memmap.
>
> What kind of system are you testing GRUB 2 (EFI) on? It would be nice
> to know which systems are already supported.
This
[EMAIL PROTECTED] writes:
Hi,
First of all, thanks a lot for this patch.
> some systems have a really big memmap.
What kind of system are you testing GRUB 2 (EFI) on? It would be nice
to know which systems are already supported.
> This patch remove the memmap size limit.
Cool. Can you pleas
Hi,
some systems have a really big memmap.
This patch remove the memmap size limit.
Tristan.
mm.diffs
Description: Binary data
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
On 9/14/06, Vesa Jääskeläinen <[EMAIL PROTECTED]> wrote:
Hi,
Sorry for my late reply.
Well, perhaps QEMU just doesn't support that mode...
I tried this sequence with exception (set gfxmode=1024x768x32) in VMWare
and it works nicely. You can specify "set gfxmode=1024x768" to auto
detect best
28 matches
Mail list logo
