efi platform and multiboot kernel
I've just edumacated myself about how the platforms are defined. Let me get this straight, the efi platform does not yet support loading a multiboot kernel? I'm working with embedded kernels here, not just Linux. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub EFI "too little memory"
On Tue, Jun 17, 2008 at 3:01 PM, David Holloway <[EMAIL PROTECTED]> wrote: >/ Intended for Robert Millan, et. al./ > >/ I have an Intel 1U server board that fails with the current version of grub/ >/ with the message "too little memory", as in line 312 of CVS version 1.4 of/ >/ grub2/kern/efi/mm.c/ >/ The board is described here:/ >/ http://www.intel.com/design/telecom/products/cbp/ipserver/9979/overview.htm/ > >/ I added some debug and I think "required_pages" at line 312 has a value of/ >/ 1MB (256 pages), consistent with MIN_HEAP./ >/ mmap from the EFI shell reports just 38 pages of LoaderData and just 196/ >/ pages of LoaderCode./ > >/ It's my intention to bone up on EFI, but I'm not there yet./ > >/ The question: does just 38 pages of LoaderData make sense in this/ >/ implemetation? is MIN_HEAP too large or does this EFI implementation provide/ >/ too little memory to be practical?/ Hi, I think this problem is caused by memory map. In new machine, the memory map is quite large, the default value in mm.c is too low for the whole map. You can change the value of #define MEMORY_MAP_SIZE 0x1000 and retry again. For example, with my macbook, I need to set this value to 0x4000. Exactly on target. Then we need a more robust and permanent solution I think right? How about asking with 0 sized buffer first knowing it will fail then asking with a rounded-up buffer the 2nd time. I can coded it, but I can't check it in of course. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub EFI "too little memory"
David Holloway wrote: Intended for Robert Millan, et. al. I have an Intel 1U server board that fails with the current version of grub with the message "too little memory", as in line 312 of CVS version 1.4 of grub2/kern/efi/mm.c The board is described here: http://www.intel.com/design/telecom/products/cbp/ipserver/9979/overview.htm I added some debug and I think "required_pages" at line 312 has a value of 1MB (256 pages), consistent with MIN_HEAP. mmap from the EFI shell reports just 38 pages of LoaderData and just 196 pages of LoaderCode. It's my intention to bone up on EFI, but I'm not there yet. The question: does just 38 pages of LoaderData make sense in this implemetation? is MIN_HEAP too large or does this EFI implementation provide too little memory to be practical? I diagnosed the root problem. The NSW1U board requires 7872 bytes for its memory map during the EFI GetMemoryMap call, but only 4096 are supplied. Obviously my short term solution is to increase MEMORY_MAP_SIZE from 0x1000 to 0x2000, but one wonders what the robust solution should be instead. In fact, I now have the NSW1U server board working after this change. I'm now filing a bug report on the matter. https://savannah.gnu.org/bugs/index.php?23615 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
grub EFI "too little memory"
Intended for Robert Millan, et. al. I have an Intel 1U server board that fails with the current version of grub with the message "too little memory", as in line 312 of CVS version 1.4 of grub2/kern/efi/mm.c The board is described here: http://www.intel.com/design/telecom/products/cbp/ipserver/9979/overview.htm I added some debug and I think "required_pages" at line 312 has a value of 1MB (256 pages), consistent with MIN_HEAP. mmap from the EFI shell reports just 38 pages of LoaderData and just 196 pages of LoaderCode. It's my intention to bone up on EFI, but I'm not there yet. The question: does just 38 pages of LoaderData make sense in this implemetation? is MIN_HEAP too large or does this EFI implementation provide too little memory to be practical? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Multiboot Specification
On Sunday 24 February 2008 13:01, Vegard Nossum wrote: My rationale is that it may be difficult to ensure that the header in fact resides within the first 8 KB of the kernel image. Actually it is quite easy to ensure the header is within the first 8KB. Just pad the custom-object-format-of-choice with the multiboot header. The actual file will no longer be a standard object type, but will work. In practice, the 8KB limitation is not severe. Nearly every OS has a small assembly language file that ends up at the beginning of the image. Frequently, operating system vendors put pretty little copyright notices in this small assembly file. Adding a multiboot header is trivial. If one must mingle the multiboot header with executable code, just add a jmp instruction around the header. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
