Re: [PATCH] badram filtering
Very interesting. I have following suggestions: 1) define platform independent way to enumerate memory map. This function wouldn't mark types with GRUB_MACHINE_* but with one of the following types: GRUB_MMAP_HOLE - means that at this position there is no RAM at all. Should this be iterated at all? GRUB_MMAP_IO - usable only by I/O drivers GRUB_MMAP_FREE - usable by ACPI and firmware-unaware OS. But may be unusable by grub itself. memory allocator should be used for requesting memory in grub GRUB_MMAP_ACPI - usable by ACPI-aware OS after loading tables GRUB_MMAP_PLATFORM_FIRST...GRUB_MMAP_PLATFORM_LAST - platform specific types which can't be used except by firmware-aware code and OS 2) when badram variable is set corresponding memory chunks should be removed from memory manager 3) add a method to specify badram in init.c so that grub2 itself has no risk of using any of this memory. I propose to embed initial environment in core.img. Then prefix and root can be changed to use this mechanism. It would also be able to override this initial environment through multiboot command line when grub2 is loaded by multiboot loader Robert Millan wrote: Hi, This patch implements badram filtering in GRUB. It's the same idea as in http://rick.vanrein.org/linux/badram/ but applied to GRUB. The badram module sits between loaders (or other users like lsmmap) and filters the mmap entries, but only when user previously set the badram variable (whose syntax is the same as the one in badram patch for Linux). NOTE this won't affect loadees that get the memory map from BIOS instead of from GRUB. This means it currently works for Multiboot and for the new/experimental Linux loader. ___ 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] parttool
Sorry I forgot include/grub/parttool.h
phcoder wrote:
Hello here is the implementation of parttool with the syntax I proposed
earlier and equivalent of parttype, makeactive and hide/unhide
--
Regards
Vladimir 'phcoder' Serbinenko
/*
* 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 http://www.gnu.org/licenses/.
*/
#ifndef GRUB_PARTTOOL_HEADER
#define GRUB_PARTTOOL_HEADER 1
struct grub_parttool_argdesc
{
char *name;
char *desc;
enum {GRUB_PARTTOOL_ARG_END, GRUB_PARTTOOL_ARG_BOOL, GRUB_PARTTOOL_ARG_VAL}
type;
};
struct grub_parttool_args
{
int set;
union
{
int bool;
char *str;
};
};
typedef grub_err_t (*grub_parttool_function_t) (const grub_device_t dev,
const struct grub_parttool_args *args);
struct grub_parttool
{
struct grub_parttool *next;
char *name;
int handle;
int nargs;
struct grub_parttool_argdesc *args;
grub_parttool_function_t func;
};
int grub_parttool_register(const char *part_name,
const grub_parttool_function_t func,
const struct grub_parttool_argdesc *args);
void grub_parttool_unregister (int handle);
#endif /* ! GRUB_PARTTOOL_HEADER*/
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] badram filtering
I've looked in depth in memory map and have seen that (1) is already done so except for EFI systems. And except that memory types are defined on per-machine basis. IMO generic memory types should be shared at the output of grub_machine_memory_iterate but it's not critical. I will code a similar function for EFI and adapt multiboot loader for EFI systems phcoder wrote: Very interesting. I have following suggestions: 1) define platform independent way to enumerate memory map. This function wouldn't mark types with GRUB_MACHINE_* but with one of the following types: GRUB_MMAP_HOLE - means that at this position there is no RAM at all. Should this be iterated at all? GRUB_MMAP_IO - usable only by I/O drivers GRUB_MMAP_FREE - usable by ACPI and firmware-unaware OS. But may be unusable by grub itself. memory allocator should be used for requesting memory in grub GRUB_MMAP_ACPI - usable by ACPI-aware OS after loading tables GRUB_MMAP_PLATFORM_FIRST...GRUB_MMAP_PLATFORM_LAST - platform specific types which can't be used except by firmware-aware code and OS 2) when badram variable is set corresponding memory chunks should be removed from memory manager 3) add a method to specify badram in init.c so that grub2 itself has no risk of using any of this memory. I propose to embed initial environment in core.img. Then prefix and root can be changed to use this mechanism. It would also be able to override this initial environment through multiboot command line when grub2 is loaded by multiboot loader Robert Millan wrote: Hi, This patch implements badram filtering in GRUB. It's the same idea as in http://rick.vanrein.org/linux/badram/ but applied to GRUB. The badram module sits between loaders (or other users like lsmmap) and filters the mmap entries, but only when user previously set the badram variable (whose syntax is the same as the one in badram patch for Linux). NOTE this won't affect loadees that get the memory map from BIOS instead of from GRUB. This means it currently works for Multiboot and for the new/experimental Linux loader. ___ 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
Boot delay when using grub.efi on Mac Mini
I installed EFI grub (svn r2024) on a Mac Mini (1.8GHz Core 2
Duo) following the instructions at http://grub.enbug.org/TestingOnEFI.
Grub seems to work fine: the menu works, and I can either boot
a Linux kernel or I can chainload OS X via /usr/standalone/i386/boot.efi.
I had previously attempted to use elilo (an old binary I
downloaded from somewhere), but it didn't seem to be able to
load the initrd correctly.
There do seem to be two problems -- I don't think either of
them are grub's fault, but I thought I ask just in case
somebody has seen either one before:
1) I blessed grub.efi using this command adapted from the Wiki page:
bash-3.2# bless --mount=/efi --verbose --file=/efi/grub/grub.efi
--setBoot
EFI found at IODeviceTree:/efi
Mount point for /efi is /efi
Mount point is '/efi'
No BootX creation requested
No boot.efi creation requested
GPT detected
Booter partition required at index 2
System partition found
Returning booter information dictionary:
CFDictionary 0x109320 [0xa08891a0]{type = mutable, count = 3,
capacity = 3, pairs = (
0 : CFString 0x18db0 [0xa08891a0]{contents = Auxiliary
Partitions} = CFArray 0x103a80 [0xa08891a0]{type = immutable, count = 0,
values = (
)}
2 : CFString 0x18da0 [0xa08891a0]{contents = Data
Partitions} = CFArray 0x109770 [0xa08891a0]{type = immutable, count = 1,
values = (
0 : CFString 0x109750 [0xa08891a0]{contents = disk0s1}
)}
3 : CFString 0x18dc0 [0xa08891a0]{contents = System
Partitions} = CFArray 0x104ff0 [0xa08891a0]{type = immutable, count = 1,
values = (
0 : CFString 0x109670 [0xa08891a0]{contents = disk0s1}
)}
)}
Relative path of /efi/grub/grub.efi is \grub\grub.efi
IOMedia disk0s1 has UUID CD08BC7E-4A45-4814-A27A-7FA6D02A2F3A
Setting EFI NVRAM:
efi-boot-device='arraydictkeyIOMatch/keydictkeyIOProviderClass/keystringIOMedia/stringkeyIOPropertyMatch/keydictkeyUUID/keystringCD08BC7E-4A45-4814-A27A-7FA6D02A2F3A/string/dict/dictkeyBLLastBSDName/keystringdisk0s1/string/dictdictkeyIOEFIDevicePathType/keystringMediaFilePath/stringkeyPath/keystring\grub\grub.efi/string/dict/array'
Setting EFI NVRAM:
IONVRAM-DELETE-PROPERTY='efi-boot-file'
Setting EFI NVRAM:
IONVRAM-DELETE-PROPERTY='efi-boot-mkext'
NVRAM variable boot-args not set.
Now the machine boots into grub, but there's about a 30
second delay between the chime and when grub starts (it
was the same for elilo). If I have a USB flash drive
plugged in, I see the activity LED flash once every 2
seconds or so until grub starts.
If I hold down the option key on startup, there is no
delay and I immediately get the screen where I click on a
button underneath a picture of a hard-drive to boot.
Any ideas on how to eliminate the 30s delay?
2) With the linux kernel command line option video=vesafb, I
get a working console, framebuffer graphics don't work.
Without that option, I don't get a working console. It's
not a grub problem, but any pointers will be appreciated.
--
Grant Edwards grante Yow! Wow! Look!! A stray
at meatball!! Let's interview
visi.comit!
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Boot delay when using grub.efi on Mac Mini
On 2009-03-10, Grant Edwards gra...@visi.com wrote: I installed EFI grub (svn r2024) on a Mac Mini (1.8GHz Core 2 Duo) following the instructions at http://grub.enbug.org/TestingOnEFI. Grub seems to work fine: the menu works, and I can either boot a Linux kernel or I can chainload OS X via /usr/standalone/i386/boot.efi. One more problem I haven't figured out: the control keys don't work (known issue), so after you've edited a menu entry, how do you boot it? -- Grant Edwards grante Yow! Quick, sing me the at BUDAPEST NATIONAL ANTHEM!! visi.com ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Search command.
Hi,
I am playing with the search command in grub2 from debian experimental
and have noticed some oddness
The search command currently returns the device as hdX,X rather than
(hdX,X). This means that the variable created using -s can't be used as
a replacement for the device string. For Example I'd like to be able to
do this:
# Set our root device
search -f /grub/grub.cfg -s root
# Set our prefix
set prefix=${root}/grub/ # I think broken variable handling means this
doesn't work.
menuentry My Linux OS {
search -s LINUX_ROOT -u ----
set root=$LINUX_ROOT
linux=/vmlinuz
initrd=/intrd.img
}
Or do I completely misunderstand the search command and usage of
variables?
--
Daniel Reurich
Centurion Computer Technology (2005) Limited.
Ph: 021 797 722
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Boot delay when using grub.efi on Mac Mini
Hi, Try the other instructions for MacBook http://grub.enbug.org/TestingOnMacbook ( recentlu updated ) including bless --folder --file --setBoot (not --mount) Some more tests done at ubuntuforums.org http://ubuntuforums.org/showthread.php?t=995704 On Wed, Mar 11, 2009 at 10:48 AM, Grant Edwards gra...@visi.com wrote: On 2009-03-10, Grant Edwards gra...@visi.com wrote: I installed EFI grub (svn r2024) on a Mac Mini (1.8GHz Core 2 Duo) following the instructions at http://grub.enbug.org/TestingOnEFI. Grub seems to work fine: the menu works, and I can either boot a Linux kernel or I can chainload OS X via /usr/standalone/i386/boot.efi. One more problem I haven't figured out: the control keys don't work (known issue), so after you've edited a menu entry, how do you boot it? -- Grant Edwards grante Yow! Quick, sing me the at BUDAPEST NATIONAL ANTHEM!! visi.com ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Boot delay when using grub.efi on Mac Mini
On 2009-03-11, Peter Cros pxwp...@gmail.com wrote: Hi, Try the other instructions for MacBook http://grub.enbug.org/TestingOnMacbook ( recentlu updated ) including bless --folder --file --setBoot (not --mount) I'll try it. Why does one Wiki page say to use folder mode, and the other to use mount mode? Some more tests done at ubuntuforums.org http://ubuntuforums.org/showthread.php?t=995704 I've already spent quite a bit of time reading that thread. If there is any useful info in there, the odds of stumbling across it are awfully remote. There are 371 posts over about 1-1/2 years, and I've never been able to get the search facility to do anything at all useful. -- Grant ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Search command.
On Wed, 2009-03-11 at 13:34 +1300, Centurion Computer Technology (2005)
Ltd wrote:
Hi,
I am playing with the search command in grub2 from debian experimental
and have noticed some oddness
The search command currently returns the device as hdX,X rather than
(hdX,X). This means that the variable created using -s can't be used as
a replacement for the device string.
Actually, you can assign it to the root variable and use relative path.
You don't need parentheses in the root variable.
For Example I'd like to be able to
do this:
# Set our root device
search -f /grub/grub.cfg -s root
# Set our prefix
set prefix=${root}/grub/ # I think broken variable handling means this
doesn't work.
True. Variable expansion is broken. But you can use
set prefix=/grub/
That would allow you to load more modules as long as $root is unchanged.
menuentry My Linux OS {
search -s LINUX_ROOT -u ----
set root=$LINUX_ROOT
This is broken for the same reason. But this would work:
search -s root -u ----
Or do I completely misunderstand the search command and usage of
variables?
You understand it correctly. But the implementation is limited.
--
Regards,
Pavel Roskin
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
