Re: I need some help with gfxterm
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 color mode. Thanks for the tip, "set gfxmode=1024x768" works fine. I want to load these modules in "grub.cfg" file, puting them in the top of the file doesn't work but making a menu entery that load them works fine, is this normal ? Now I'm able to display menu enteries in Arabic. Although grub2 deosn't support RTL nor Arabic shaping, a quicke workaround is to store the Arabic text in grub.cfg already Shapped by using a tool like fribidi2 (cvs branch) or "mu" [ftp://foolab.org/tmp/mu-fribidi.zip] $ mu < grub.cfg > grub_ar.cfg then coping "grub_ar.cfg" to grub/grub.cfg. Here a screenshoot without RTL and shaping [http://khalid_hosny.manalaa.net/files/khalid_hosny/images/grub3.preview.png] , and this one with [http://khalid_hosny.manalaa.net/files/khalid_hosny/images/grub2.png]. Also I wrote a mini-howto in Arabic [http://khalid_hosny.manalaa.net/grub2_arabic_howto] if any one interested -- Khaled Hosny Egyptian GNU/Linux user Member of Arabeyes translation team [www.arabeyes.org] My Blog: [khalid_hosny.manalaa.net] ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
patch for kern/efi/mm.c (big memmap)
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
Re: patch for kern/efi/mm.c (big memmap)
[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 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 being sent inline so it is easier to read and to give feedback on. Thanks, Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: patch for kern/efi/mm.c (big memmap)
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 is on an ia64 system (Tiger).
> > This patch remove the memmap size limit.
>
> 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 being sent inline so it is easier to read and to
> give feedback on.
Sorry, this is my first patch!
Tristan.
2006-09-28 Tristan Gingold <[EMAIL PROTECTED]>
* kern/efi/mm.c (grub_efi_mm_init): MEMORY_MAP_SIZE removed,
dynamically get the size of the memory map.
--- grub2.cvs/kern/efi/mm.c 2006-05-29 01:01:43.0 +0200
+++ grub2/kern/efi/mm.c 2006-09-28 11:25:47.0 +0200
@@ -30,10 +30,6 @@
#define BYTES_TO_PAGES(bytes) ((bytes) >> 12)
#define PAGES_TO_BYTES(pages) ((pages) << 12)
-/* The size of a memory map obtained from the firmware. This must be
- a multiplier of 4KB. */
-#define MEMORY_MAP_SIZE0x1000
-
/* Maintain the list of allocated pages. */
struct allocated_page
{
@@ -346,6 +342,8 @@
grub_efi_uintn_t desc_size;
grub_efi_uint64_t total_pages;
grub_efi_uint64_t required_pages;
+ grub_efi_uintn_t memory_map_size;
+ int res;
/* First of all, allocate pages to maintain allocations. */
allocated_pages
@@ -356,15 +354,20 @@
grub_memset (allocated_pages, 0, ALLOCATED_PAGES_SIZE);
/* Prepare a memory region to store two memory maps. */
- memory_map = grub_efi_allocate_pages (0,
- 2 * BYTES_TO_PAGES (MEMORY_MAP_SIZE));
+ memory_map_size = 0;
+ res = grub_efi_get_memory_map (&memory_map_size, NULL, 0, &desc_size, 0);
+ if (res != 0)
+grub_fatal ("cannot get memory map size");
+
+ memory_map = grub_efi_allocate_pages
+(0, 2 * BYTES_TO_PAGES (memory_map_size + 0x1000));
if (! memory_map)
grub_fatal ("cannot allocate memory");
- filtered_memory_map = NEXT_MEMORY_DESCRIPTOR (memory_map, MEMORY_MAP_SIZE);
+ filtered_memory_map = NEXT_MEMORY_DESCRIPTOR (memory_map, memory_map_size);
/* Obtain descriptors for available memory. */
- map_size = MEMORY_MAP_SIZE;
+ map_size = memory_map_size;
if (grub_efi_get_memory_map (&map_size, memory_map, 0, &desc_size, 0) < 0)
grub_fatal ("cannot get memory map");
@@ -373,7 +376,7 @@
filtered_memory_map_end = filter_memory_map (memory_map, filtered_memory_map,
desc_size, memory_map_end);
-
+
/* By default, request a quarter of the available memory. */
total_pages = get_total_pages (filtered_memory_map, desc_size,
filtered_memory_map_end);
@@ -393,7 +396,7 @@
#if 0
/* For debug. */
- map_size = MEMORY_MAP_SIZE;
+ map_size = memory_map_size;
if (grub_efi_get_memory_map (&map_size, memory_map, 0, &desc_size, 0) < 0)
grub_fatal ("cannot get memory map");
@@ -406,7 +409,7 @@
/* Release the memory maps. */
grub_efi_free_pages ((grub_addr_t) memory_map,
- 2 * BYTES_TO_PAGES (MEMORY_MAP_SIZE));
+ 2 * BYTES_TO_PAGES (memory_map_size + 0x1000));
}
void
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub for ia64
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 can fit for all architectures. why write different grub_efi_allocate_pages/grub_efi_free_boot_pages, we can modify these two functions to fit for all architecture EFI platform. thanks bibo,mao [EMAIL PROTECTED] wrote: Hi this is a port of grub2 to ia64. ia64 systems (itanium) are EFI based so this port reuse existing EFI infrastructure. I have made 4 patches: efi64.diffs: fix a 64 bits issue of efi/api.h fat.diffs: fix 64bits issues and make filename match case insensitive. [I think most 64 bits issues have already been reported recently and independently by the mail grub2 64bit system compatible] ia64.diffs: ia64 specific files modules.diffs: currently the ia64 port cannot load modules. This patch makes slight changes so that grub can be completly prelinked without removing the dynamic loading feature. I think it is worth for three reasons: * it makes initial port easier. * the current common code can't work on ia64 (on ia64 a function pointer is a descriptor and not the address of the first function instruction). * grub-emu doesn't have dynamic modules and could reuse this work to remove most of #ifdef/#endif GRUB_UTIL I have also written a few additionnal EFI specific commands I will post later. Tristan. ___ 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: Grub for ia64
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 > on arch specific place. Function find_mmap_size can fit for all > architectures. Correct. > why write different grub_efi_allocate_pages/grub_efi_free_boot_pages, we > can > modify these two functions to fit for all architecture EFI platform. They are slightly different. Pages allocated by grub_efi_allocate_boot_pages won't be freed at grub exit. This is very important to load linux/initrd/modules on pages which won't be touched! These functions could be moved to kern/efi/mm.c. Tristan. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub for ia64
[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 are copyrighted by Hewlett-Packard and David Mosberger-Tang. All developers of GNU GRUB has agreed to sign over their copyright to FSF, so brining non-FSF copyrighted code into the project is a problem (and likely a show-stopper). There are also a few files that are released under LGPL. Maintainers, are there any problems with bringing such files into GNU GRUB? 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? If it doesn't, my gut feeling tells me that this should be in libgcc. There were also a few files without any copyright notice what so ever (trampoline.S being one). Please add a boilerplate. I noticed that there were a generic fix for grub_strtoull in the fat patch; maybe you could send that, and other generic fixes as separate patches? Also, do not forget ChangeLog [1] entries for all your changes. If you are not familiar with writing ChangeLogs, we'll of course help you with that. Have you signed over copyright to FSF for your work on GNU GRUB? In other words, have you sent in an assignment record to FSF? If not, let us know and we'll send you a request record. Anyhow, when I get a few more minutes over I'll try to review your patches more in depth. I do not know if there is a policy for how to contribute code to GRUB, but please send unified diffs (-u) instead of context diffs (-c). I at least find them easier to read. ~j [1] http://www.gnu.org/prep/standards/html_node/Change-Logs.html pgpuJqKuDuLuM.pgp Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub for ia64
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 brining non-FSF copyrighted code into > the project is a problem (and likely a show-stopper). If code from third parties is used it will be a show stopper, especially in such cases. > There are also a few files that are released under LGPL. Maintainers, > are there any problems with bringing such files into GNU GRUB? What do you mean by that? Code written for the IA64 port or brought in from elsewhere? > Have you signed over copyright to FSF for your work on GNU GRUB? In > other words, have you sent in an assignment record to FSF? If not, > let us know and we'll send you a request record. Okuji or me will talk to contributors off-list usually about such issues, so that won't be a problem. > Anyhow, when I get a few more minutes over I'll try to review your > patches more in depth. Thanks a lot for doing this! > I do not know if there is a policy for how to contribute code to GRUB, > but please send unified diffs (-u) instead of context diffs (-c). I > at least find them easier to read. Like mentioned in the other emails, I want unified diffs (diff -up) inlined in the email with a Changelog entry. This is correctly picked up in the patch in the other thread so I am confident it will work out fine for the port as well. :-) -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub for ia64
[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 the patches and write changelog entries. I like that you split up the patches so they can be reviewed and separately. Next week or weeks I will be quite busy and won't have time for GRUB hacking or to review patches. But I will try to do so ASAP, or hopefully Okuji will have the time to do so. I hope you will be patient, I want this in ASAP. :) > fat.diffs: fix 64bits issues and make filename match case insensitive. 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. But I am afraid this might not be a generic solution so I hope we can discuss the problem first. > > [I think most 64 bits issues have already been reported recently and > independently by the mail grub2 64bit system compatible] Cool. I assume these patches are in CVS now? > modules.diffs: > currently the ia64 port cannot load modules. This patch makes slight changes > so that grub can be completly prelinked without removing the dynamic loading > feature. > I think it is worth for three reasons: > * it makes initial port easier. Right, we had that with the PPC port too. I will have a look if it doesn't break anything for other archs. I hope you are willing to implement whatever is required for module loading for IA64. Module loading is an essential part of the GRUB 2 design and I prefer having the same behavior for every port. > * the current common code can't work on ia64 (on ia64 a function pointer is a > descriptor and not the address of the first function instruction). Can you give some examples by using code? Certainly we would have to aim for module loading at some point in time. :) > * grub-emu doesn't have dynamic modules and could reuse this work to remove > most of #ifdef/#endif GRUB_UTIL *Please* do not mess around too much with grub-emu. I can perfectly understand why people want all kind of things changed in grub-emu and I would certainly like to have module support there (IIRC there were patches sent in, some of which I still have to review, etc :-/). It's important to know why I wrote grub-emu. It is mainly a debugging tool. For example you don't want to implement a filesystem or work on the commandline interface without such tool. Having module loading only is just annoying so GRUB_UTIL can't and won't be removed. Actually, it is technically almost impossible to do modules loading in every case on every processor. For example take the PPC, some relocations are almost impossible or very hard to implement in userspace. > I have also written a few additionnal EFI specific commands I will post later. I am looking forwards to your patches. Thanks, Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: patch for kern/efi/mm.c (big memmap)
[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 being sent inline so it is easier to read and to >> give feedback on. > Sorry, this is my first patch! Hopefully you didn't see my feedback as evil comments ;-). My reason to tell you all this is to get patches in the form we would like to see them for easy review and quick integration. > Tristan. > > 2006-09-28 Tristan Gingold <[EMAIL PROTECTED]> > > * kern/efi/mm.c (grub_efi_mm_init): MEMORY_MAP_SIZE removed, > dynamically get the size of the memory map. Great. There are a few changes I will make before committing this patch. Please have a look at the commit email to see what was changed and why. I will most likely commit this patch Sunday evening, certainly not before that, sorry. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub for ia64
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 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 brining non-FSF copyrighted code into > the project is a problem (and likely a show-stopper). I was not aware of this policy. > There are also a few files that are released under LGPL. Maintainers, > are there any problems with bringing such files into GNU GRUB? > > 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. Yes, most should be either in glibc or libgcc. > There were also a few files without any copyright notice what so ever > (trampoline.S being one). Please add a boilerplate. Ok. > I noticed that there were a generic fix for grub_strtoull in the fat > patch; maybe you could send that, and other generic fixes as separate > patches? Also, do not forget ChangeLog [1] entries for all your > changes. If you are not familiar with writing ChangeLogs, we'll of > course help you with that. Ok. > Have you signed over copyright to FSF for your work on GNU GRUB? In > other words, have you sent in an assignment record to FSF? If not, > let us know and we'll send you a request record. NO. Please send me the request record. Note: this work currently belongs to my employer (Bull SAS). > Anyhow, when I get a few more minutes over I'll try to review your > patches more in depth. > > I do not know if there is a policy for how to contribute code to GRUB, > but please send unified diffs (-u) instead of context diffs (-c). I > at least find them easier to read. Oops, sorry. Tristan. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to install a module into the kernel
袁源 <[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 very > glad if you can help me solve this. You can use the grub-mkimage command to add the modules, like you had to do for all the other modules as well. What kind of modules did you write? Can we expect any patches? :-) -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: patch for kern/efi/mm.c (big memmap)
[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 (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.
I'll attach a unified diff, since those is easier to review.
Even through this patch is quite trivial and small, I believe we need
you to sign over the copyright for it to FSF. Okuji, Marco, what are
your opinions?
~j
Index: kern/efi/mm.c
===
RCS file: /sources/grub/grub2/kern/efi/mm.c,v
retrieving revision 1.3
diff -u -r1.3 mm.c
--- kern/efi/mm.c 28 May 2006 23:01:43 - 1.3
+++ kern/efi/mm.c 28 Sep 2006 13:29:16 -
@@ -30,10 +30,6 @@
#define BYTES_TO_PAGES(bytes) ((bytes) >> 12)
#define PAGES_TO_BYTES(pages) ((pages) << 12)
-/* The size of a memory map obtained from the firmware. This must be
- a multiplier of 4KB. */
-#define MEMORY_MAP_SIZE 0x1000
-
/* Maintain the list of allocated pages. */
struct allocated_page
{
@@ -346,6 +342,8 @@
grub_efi_uintn_t desc_size;
grub_efi_uint64_t total_pages;
grub_efi_uint64_t required_pages;
+ grub_efi_uintn_t memory_map_size;
+ int res;
/* First of all, allocate pages to maintain allocations. */
allocated_pages
@@ -356,15 +354,20 @@
grub_memset (allocated_pages, 0, ALLOCATED_PAGES_SIZE);
/* Prepare a memory region to store two memory maps. */
- memory_map = grub_efi_allocate_pages (0,
- 2 * BYTES_TO_PAGES (MEMORY_MAP_SIZE));
+ memory_map_size = 0;
+ res = grub_efi_get_memory_map (&memory_map_size, NULL, 0, &desc_size, 0);
+ if (res != 0)
+grub_fatal ("cannot get memory map size");
+
+ memory_map = grub_efi_allocate_pages
+(0, 2 * BYTES_TO_PAGES (memory_map_size + 0x1000));
if (! memory_map)
grub_fatal ("cannot allocate memory");
- filtered_memory_map = NEXT_MEMORY_DESCRIPTOR (memory_map, MEMORY_MAP_SIZE);
+ filtered_memory_map = NEXT_MEMORY_DESCRIPTOR (memory_map, memory_map_size);
/* Obtain descriptors for available memory. */
- map_size = MEMORY_MAP_SIZE;
+ map_size = memory_map_size;
if (grub_efi_get_memory_map (&map_size, memory_map, 0, &desc_size, 0) < 0)
grub_fatal ("cannot get memory map");
@@ -373,7 +376,7 @@
filtered_memory_map_end = filter_memory_map (memory_map, filtered_memory_map,
desc_size, memory_map_end);
-
+
/* By default, request a quarter of the available memory. */
total_pages = get_total_pages (filtered_memory_map, desc_size,
filtered_memory_map_end);
@@ -393,7 +396,7 @@
#if 0
/* For debug. */
- map_size = MEMORY_MAP_SIZE;
+ map_size = memory_map_size;
if (grub_efi_get_memory_map (&map_size, memory_map, 0, &desc_size, 0) < 0)
grub_fatal ("cannot get memory map");
@@ -406,7 +409,7 @@
/* Release the memory maps. */
grub_efi_free_pages ((grub_addr_t) memory_map,
- 2 * BYTES_TO_PAGES (MEMORY_MAP_SIZE));
+ 2 * BYTES_TO_PAGES (memory_map_size + 0x1000));
}
void
pgpVb9rWYYhjw.pgp
Description: PGP signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: patch for kern/efi/mm.c (big memmap)
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? > I'll attach a unified diff, since those is easier to review. Wow, I have two unified diffs now, you both make my day. ;-) > Even through this patch is quite trivial and small, I believe we need > you to sign over the copyright for it to FSF. Okuji, Marco, what are > your opinions? This patch is trivial enough to apply without the paperwork, I think. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub for ia64
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 comment as for your other emails. Please use > diff -up and inline the patches and write changelog entries. I like > that you split up the patches so they can be reviewed and separately. > > Next week or weeks I will be quite busy and won't have time for GRUB > hacking or to review patches. But I will try to do so ASAP, or > hopefully Okuji will have the time to do so. I hope you will be > patient, I want this in ASAP. :) > > > fat.diffs: fix 64bits issues and make filename match case insensitive. > > 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. > But I am afraid this might not be a generic > solution so I hope we can discuss the problem first. I suppose you can't use mixed case filename currently for FAT fs. This patch fixes that. > > [I think most 64 bits issues have already been reported recently and > > independently by the mail grub2 64bit system compatible] > > Cool. I assume these patches are in CVS now? AFAIK not yet integrated. > > modules.diffs: > > currently the ia64 port cannot load modules. This patch makes slight > changes > > so that grub can be completly prelinked without removing the dynamic > loading > > feature. > > I think it is worth for three reasons: > > * it makes initial port easier. > > Right, we had that with the PPC port too. I will have a look if it > doesn't break anything for other archs. > > I hope you are willing to implement whatever is required for module > loading for IA64. Module loading is an essential part of the GRUB 2 > design and I prefer having the same behavior for every port. Sure. > > * the current common code can't work on ia64 (on ia64 a function pointer is > a > > descriptor and not the address of the first function instruction). > > Can you give some examples by using code? Certainly we would have to > aim for module loading at some point in time. :) Yes, cf kern/dl.c: if (grub_strcmp (name, "grub_mod_init") == 0) mod->init = (void (*) (grub_dl_t)) sym->st_value; This won't work on ia64 AFAIK. > > * grub-emu doesn't have dynamic modules and could reuse this work to remove > > most of #ifdef/#endif GRUB_UTIL > > *Please* do not mess around too much with grub-emu. I can perfectly > understand why people want all kind of things changed in grub-emu and > I would certainly like to have module support there (IIRC there were > patches sent in, some of which I still have to review, etc :-/). > > It's important to know why I wrote grub-emu. It is mainly a debugging > tool. For example you don't want to implement a filesystem or work on > the commandline interface without such tool. Having module loading > only is just annoying so GRUB_UTIL can't and won't be removed. >From my point of view, GRUB_UTIL could be removed without adding modules to grub-emu. This would be slightly cleaner. > Actually, it is technically almost impossible to do modules loading in > every case on every processor. For example take the PPC, some > relocations are almost impossible or very hard to implement in > userspace. Looks strange. How does ld.so works on these systems ? > > I have also written a few additionnal EFI specific commands I will post > later. > > I am looking forwards to your patches. Ok. Thanks, Tristan. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub for ia64
[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. > Yes, most should be either in glibc or libgcc. I have not verified this completely, but it seems as libgcc has all these routines at hand. GCC also has the following IA-64 options that might be usefull; `-minline-int-divide-min-latency' Generate code for inline divides of integer values using the minimum latency algorithm. `-minline-int-divide-max-throughput' Generate code for inline divides of integer values using the maximum throughput algorithm. ~j pgp076emLpWSW.pgp Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: patch for kern/efi/mm.c (big memmap)
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 as well?
Done. See attached patch.
>> Even through this patch is quite trivial and small, I believe we
>> need you to sign over the copyright for it to FSF. Okuji, Marco,
>> what are your opinions?
>
> This patch is trivial enough to apply without the paperwork, I
> think.
OK.
I'll commit it after I get a few minutes over to test it.
~j
Index: kern/efi/mm.c
===
RCS file: /sources/grub/grub2/kern/efi/mm.c,v
retrieving revision 1.3
diff -u -p -r1.3 mm.c
--- kern/efi/mm.c 28 May 2006 23:01:43 - 1.3
+++ kern/efi/mm.c 28 Sep 2006 13:57:30 -
@@ -27,13 +27,9 @@
#define NEXT_MEMORY_DESCRIPTOR(desc, size) \
((grub_efi_memory_descriptor_t *) ((char *) (desc) + (size)))
-#define BYTES_TO_PAGES(bytes) ((bytes) >> 12)
+#define BYTES_TO_PAGES(bytes) (((bytes) + 4095) >> 12)
#define PAGES_TO_BYTES(pages) ((pages) << 12)
-/* The size of a memory map obtained from the firmware. This must be
- a multiplier of 4KB. */
-#define MEMORY_MAP_SIZE 0x1000
-
/* Maintain the list of allocated pages. */
struct allocated_page
{
@@ -346,6 +342,8 @@ grub_efi_mm_init (void)
grub_efi_uintn_t desc_size;
grub_efi_uint64_t total_pages;
grub_efi_uint64_t required_pages;
+ grub_efi_uintn_t memory_map_size;
+ int res;
/* First of all, allocate pages to maintain allocations. */
allocated_pages
@@ -355,16 +353,23 @@ grub_efi_mm_init (void)
grub_memset (allocated_pages, 0, ALLOCATED_PAGES_SIZE);
- /* Prepare a memory region to store two memory maps. */
- memory_map = grub_efi_allocate_pages (0,
- 2 * BYTES_TO_PAGES (MEMORY_MAP_SIZE));
+ /* Prepare a memory region to store two memory maps. Obtain size of
+ memory map by passing a NULL buffer and a buffer size of
+ zero. */
+ memory_map_size = 0;
+ res = grub_efi_get_memory_map (&memory_map_size, NULL, 0, &desc_size, 0);
+ if (res != 0)
+grub_fatal ("cannot get memory map size");
+
+ memory_map = grub_efi_allocate_pages
+(0, 2 * BYTES_TO_PAGES (memory_map_size));
if (! memory_map)
grub_fatal ("cannot allocate memory");
- filtered_memory_map = NEXT_MEMORY_DESCRIPTOR (memory_map, MEMORY_MAP_SIZE);
+ filtered_memory_map = NEXT_MEMORY_DESCRIPTOR (memory_map, memory_map_size);
/* Obtain descriptors for available memory. */
- map_size = MEMORY_MAP_SIZE;
+ map_size = memory_map_size;
if (grub_efi_get_memory_map (&map_size, memory_map, 0, &desc_size, 0) < 0)
grub_fatal ("cannot get memory map");
@@ -393,7 +398,7 @@ grub_efi_mm_init (void)
#if 0
/* For debug. */
- map_size = MEMORY_MAP_SIZE;
+ map_size = memory_map_size;
if (grub_efi_get_memory_map (&map_size, memory_map, 0, &desc_size, 0) < 0)
grub_fatal ("cannot get memory map");
@@ -406,7 +411,7 @@ grub_efi_mm_init (void)
/* Release the memory maps. */
grub_efi_free_pages ((grub_addr_t) memory_map,
- 2 * BYTES_TO_PAGES (MEMORY_MAP_SIZE));
+ 2 * BYTES_TO_PAGES (memory_map_size));
}
void
pgpn2pvoWdXa0.pgp
Description: PGP signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: patch for kern/efi/mm.c (big memmap)
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 do roundup. >> >> Agreed. Can you make this change as well? > > Done. See attached patch. Great, I assume you can fixup the changelog entry as well? > I'll commit it after I get a few minutes over to test it. Cool. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Fix grub_strtoull
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-27 08:15:44.0 +0200
@@ -366,7 +386,7 @@
/* Guess the base, if not specified. The prefix `0x' means 16, and
the prefix `0' means 8. */
- if (str[0] == '0')
+ if (base == 0 && str[0] == '0')
{
if (str[1] == 'x')
{
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
resumo-like functionality
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
Re: Grub for ia64
[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 can discuss the problem first. > I suppose you can't use mixed case filename currently for FAT fs. This > patch fixes that. Well, I am afraid the same problem will show up when using HFS+, ext2 or whatever. So that is why I would like a detailed description of this problem (I just know there is a problem, but never received a detailed report). >> > [I think most 64 bits issues have already been reported recently and >> > independently by the mail grub2 64bit system compatible] >> >> Cool. I assume these patches are in CVS now? > AFAIK not yet integrated. Ok. Your patch relies on that? so would those have to go in first? >> > * the current common code can't work on ia64 (on ia64 a function >> > pointer is a descriptor and not the address of the first function >> > instruction). >> >> Can you give some examples by using code? Certainly we would have to >> aim for module loading at some point in time. :) > Yes, cf kern/dl.c: > > if (grub_strcmp (name, "grub_mod_init") == 0) > mod->init = (void (*) (grub_dl_t)) sym->st_value; > > This won't work on ia64 AFAIK. Why not? In the internal working of filesystems there are also function pointer being used. Same for almost every other part of GRUB 2. So I am wondering what makes this different. >> > * grub-emu doesn't have dynamic modules and could reuse this work to remove >> > most of #ifdef/#endif GRUB_UTIL >> >> *Please* do not mess around too much with grub-emu. I can perfectly >> understand why people want all kind of things changed in grub-emu and >> I would certainly like to have module support there (IIRC there were >> patches sent in, some of which I still have to review, etc :-/). >> >> It's important to know why I wrote grub-emu. It is mainly a debugging >> tool. For example you don't want to implement a filesystem or work on >> the commandline interface without such tool. Having module loading >> only is just annoying so GRUB_UTIL can't and won't be removed. >From my point of view, GRUB_UTIL could be removed without adding >modules to grub-emu. This would be slightly cleaner. Well, it's use can certainly be brought back or changed. But adding a module loader is not the way to go. If it bothers a lot of people I could change functions like grub_dl_ref into a macro which does the #ifdef. >> Actually, it is technically almost impossible to do modules loading in >> every case on every processor. For example take the PPC, some >> relocations are almost impossible or very hard to implement in >> userspace. > Looks strange. How does ld.so works on these systems ? For the PPC I once wrote a module loader (userspace). Some relocations expect the symbols you point to from the relocated code, to be within 4MB. The dynamic loader on the PPC perhaps has no problems with that because it can load code about everywhere and perhaps those relocations are normally not used, but I can be wrong. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: resumo-like functionality
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@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: resumo-like functionality
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 for pointing that out. AG ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: resumo-like functionality
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 fallback option in GRUB Legacy? > > Looks like it. Thanks for pointing that out. I forgot to mention that GRUB 2 does not have support for fallback yet, currently it is only a GRUB Legacy feature. If you would like to work with us on something similar to fallback for GRUB 2, you are more than welcome. There are some ideas about how to integrate it into GRUB 2, it just hasn't been implemented yet. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] grub-probefs --root-device
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-09-23 Robert Millan <[EMAIL PROTECTED]> > > > > * util/i386/pc/getroot.c (grub_guess_root_device): Stop using > > grub_util_biosdisk_get_grub_dev to convert system device to GRUB device. > > * util/grub-emu.c: Use grub_util_biosdisk_get_grub_dev with the string > > returned by grub_guess_root_device. > > Method name missing from grub-emu. Ok (main). > > * util/i386/pc/grub-setup.c: Ditto. > > * util/i386/pc/grub-probefs.c: Ditto. > > > > * util/i386/pc/grub-probefs.c: Rename to ... > > * util/i386/pc/grub-probe.c: ... this. > > * DISTLIST: Update reference to grub-probefs. > > * conf/i386-efi.mk: Ditto. > > * conf/i386-efi.rmk: Ditto. > > * conf/i386-pc.mk: Ditto. > > * conf/i386-pc.rmk: Ditto. > > * util/i386/pc/grub-install.in: Ditto. > > Describe what changed in terms of source code not in terms of "english". > Eg. DISTLIST: Removed grub-probefs. Added grub-probe. > > I am not sure is "ditto" a good term.. I have seen "Likewise." in other > entries and used that myself too. > > And no need to inform about changes to .mk as they are generated files. > Just make sure on commit they are there. Ok. I'm also omitting .mk files from my patch. I'll take care of regenerating later. > > * util/i386/pc/grub-probe.c: Add --target=(fs|device|drive) option to > > choose which information we want to print. > > Method... This change applies in various places of the file (main, probe, options..) > Should be grub_probe as name changes... May need changes to other places > too. Checked them all this time. > >--no-floppy do not probe any floppy drive > >--recheck probe a device map even if it already exists > > > > @@ -92,8 +92,8 @@ > > grub_mkimage=`echo "$option" | sed 's/--grub-mkimage=//'` ;; > > --grub-mkdevicemap=*) > > grub_mkdevicemap=`echo "$option" | sed 's/--grub-mkdevicemap=//'` ;; > > ---grub-probefs=*) > > - grub_probefs=`echo "$option" | sed 's/--grub-probefs=//'` ;; > > +--grub-probe=*) > > + grub_probefs=`echo "$option" | sed 's/--grub-probe=//'` ;; > > Needs change here at least... Done. Also added an explicit --target=fs option in grub-install (better be safe). Please let me know if it's ok now: 2006-09-28 Robert Millan <[EMAIL PROTECTED]> * util/i386/pc/getroot.c (grub_guess_root_device): Stop using grub_util_biosdisk_get_grub_dev to convert system device to GRUB device. * util/grub-emu.c (main): Use grub_util_biosdisk_get_grub_dev with the string returned by grub_guess_root_device. * util/i386/pc/grub-setup.c: Likewise. * util/i386/pc/grub-probefs.c: Likewise. * util/i386/pc/grub-probefs.c: Rename to ... * util/i386/pc/grub-probe.c: ... this. * DISTLIST: Remove grub-probefs, add grub-probe. * conf/i386-efi.rmk: Likewise. * conf/i386-pc.rmk: Likewise. * util/i386/pc/grub-install.in: Likewise. * util/i386/pc/grub-probe.c: Add --target=(fs|device|drive) option to choose which information we want to print. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. 2006-09-28 Robert Millan <[EMAIL PROTECTED]> * util/i386/pc/getroot.c (grub_guess_root_device): Stop using grub_util_biosdisk_get_grub_dev to convert system device to GRUB device. * util/grub-emu.c (main): Use grub_util_biosdisk_get_grub_dev with the string returned by grub_guess_root_device. * util/i386/pc/grub-setup.c: Likewise. * util/i386/pc/grub-probefs.c: Likewise. * util/i386/pc/grub-probefs.c: Rename to ... * util/i386/pc/grub-probe.c: ... this. * DISTLIST: Remove grub-probefs, add grub-probe. * conf/i386-efi.rmk: Likewise. * conf/i386-pc.rmk: Likewise. * util/i386/pc/grub-install.in: Likewise. * util/i386/pc/grub-probe.c: Add --target=(fs|device|drive) option to choose which information we want to print. Index: DISTLIST === RCS file: /sources/grub/grub2/DISTLIST,v retrieving revision 1.36 diff -u -r1.36 DISTLIST --- DISTLIST4 Jun 2006 12:59:19 - 1.36 +++ DISTLIST28 Sep 2006 14:11:04 - @@ -253,7 +253,7 @@ util/i386/pc/grub-install.in util/i386/pc/grub-mkdevicemap.c util/i386/pc/grub-mkimage.c -util/i386/pc/grub-probefs.c +util/i386/pc/grub-probe.c util/i386/pc/grub-setup.c util/i386/pc/misc.c util/powerpc/ieee1275/grub-install.in Index: conf/i386-efi.rmk ==
Re: Grub for ia64
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 determined from an EFI file path. This file path may have some components in upper case. However grub can't match a mixed file name with a FAT directory entry. We could either fix this by lowering the EFI file path or fixing the fat fs. > >> But I am afraid this might not be a generic > >> solution so I hope we can discuss the problem first. > > I suppose you can't use mixed case filename currently for FAT fs. This > > patch fixes that. > > Well, I am afraid the same problem will show up when using HFS+, ext2 > or whatever. So that is why I would like a detailed description of > this problem (I just know there is a problem, but never received a > detailed report). > > >> > [I think most 64 bits issues have already been reported recently and > >> > independently by the mail grub2 64bit system compatible] > >> > >> Cool. I assume these patches are in CVS now? > > AFAIK not yet integrated. > > Ok. Your patch relies on that? so would those have to go in first? No, No. Completly independant. > >> > * the current common code can't work on ia64 (on ia64 a function > >> > pointer is a descriptor and not the address of the first function > >> > instruction). > >> > >> Can you give some examples by using code? Certainly we would have to > >> aim for module loading at some point in time. :) > > Yes, cf kern/dl.c: > > > > if (grub_strcmp (name, "grub_mod_init") == 0) > > mod->init = (void (*) (grub_dl_t)) sym->st_value; > > > > This won't work on ia64 AFAIK. > > Why not? In the internal working of filesystems there are also > function pointer being used. Same for almost every other part of > GRUB 2. So I am wondering what makes this different. Function pointers works on ia64 (of course!) But you can't convert an address to a function pointer. This cast is not valid on ia64 (and violates the C standard). > >> > * grub-emu doesn't have dynamic modules and could reuse this work to > remove > >> > most of #ifdef/#endif GRUB_UTIL > >> > >> *Please* do not mess around too much with grub-emu. I can perfectly > >> understand why people want all kind of things changed in grub-emu and > >> I would certainly like to have module support there (IIRC there were > >> patches sent in, some of which I still have to review, etc :-/). > >> > >> It's important to know why I wrote grub-emu. It is mainly a debugging > >> tool. For example you don't want to implement a filesystem or work on > >> the commandline interface without such tool. Having module loading > >> only is just annoying so GRUB_UTIL can't and won't be removed. > > >From my point of view, GRUB_UTIL could be removed without adding > >modules to grub-emu. This would be slightly cleaner. > > Well, it's use can certainly be brought back or changed. But adding a > module loader is not the way to go. If it bothers a lot of people I > could change functions like grub_dl_ref into a macro which does the > #ifdef. I have never suggested to add module loader to grub-emu! > >> Actually, it is technically almost impossible to do modules loading in > >> every case on every processor. For example take the PPC, some > >> relocations are almost impossible or very hard to implement in > >> userspace. > > Looks strange. How does ld.so works on these systems ? > > For the PPC I once wrote a module loader (userspace). Some > relocations expect the symbols you point to from the relocated code, > to be within 4MB. The dynamic loader on the PPC perhaps has no > problems with that because it can load code about everywhere and > perhaps those relocations are normally not used, but I can be wrong. These problems are very common. You should compile with -fpic! Tristan. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub for ia64 - function descriptors
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-bit PowerPC also uses function descriptors. They look something like: long code_address long table_of_contents long unused The table_of_contents (TOC) value needs to be placed into r2 when jumping at code_address (and of course the old one needs to be restored when returning). I assume IA64 is similar here, and given that, a module_jump function implemented in assembly by each architecture would solve this problem. (Generally speaking, the TOC on ppc64 only varies across separately linked modules.) (This issue does not apply to GRUB on ppc64 systems, since those systems still use 32-bit firmware and thus 32-bit GRUB.) -Hollis ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub for ia64 - function descriptors
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 problem be solved with an architecture-specific macro? > > FWIW, 64-bit PowerPC also uses function descriptors. They look something > like: > long code_address > long table_of_contents > long unused > > The table_of_contents (TOC) value needs to be placed into r2 when > jumping at code_address (and of course the old one needs to be restored > when returning). Indeed, same issue. >I assume IA64 is similar here, and given that, a > module_jump function implemented in assembly by each architecture would > solve this problem. I'd prefer modules to export pointers. Seems to be easier to deal. Tristan. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
