grub2 and fat efi files on latest Apples
Newbie post but hopefully I will be providing some useful data rather than merely questions... I have been using the svn trunk over the last few days with some success compiling 32 and 64 bit EFI grub and creating a dual architecture grub.efi from the results that seems to work on hard disk on newer and older Apple Intel Macs. I use the fatglue.py python script from refit to make the fat grub.efi. Not sure if anyone else is doing anything similar... I have observed that fat modules don't work - need to use grub-mkimage to insert all the required modules. Another interesting observation (not really grub but maybe worth comment) is that using a Linux 2.6.29.2 kernel and initrd on the newer macs in efi mode boot (uses framebuffer console) works up until the insertion of modules. It appears that some modules do insert and other don't. The same kernel and initrd booted in "legacy mode" (after a call to fakebios) boots fine. Finally, the reboot call from linux on the iMac 9,1 hangs - possibly an issue with fakebios??? If the output of grub-dumpbios is any use let me know... Models tested (all intel) macmini iMac 4,1 requires ia32 or "fat" grub.efi iMac 8,1 requires x86_64 or "fat" grub.efi iMac 9,1 requires x86_64 or "fat" grub.efi James -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Video mode fixes in linux loader
On Mon, May 04, 2009 at 05:59:11PM -0400, BandiPat wrote: > Robert Millan wrote: >> Btw, I increased the mode list considerably (using documented modes from >> Wikipedia). Chances that your ultra-weird mode of choice is supported are >> much greater now. >> >> There's still no fuzzy matching, though. I'm not sure if we'd want to do >> that at all for vga= modes, since we already do it properly in our video >> subsystem. >> > = > I'll give them a look as soon as I can get something new built. I'll > have to admit, I didn't expect you guys to go to so much trouble, since > the vga= will be going away anyhow. We can all live with the "fuzzy > matching" for now, until you get the new video subsystem operating > properly. Don't put a lot of time into something that won't be used > much longer, as we can live with things as they are for the moment. Maybe you're right :-/ Hopefuly this will be less of a problem when we can set it from a variable using a sane interface... -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Kexec loading grub2
On Sat, May 02, 2009 at 03:04:47PM -0700, Joey Korkames wrote: >> If you use 0x10, though, the Linux loader will probably stop working. > > I'm not too worried about breaking the linux loader since kexec can load > linux directly...as long as it can load some other OS's (multiboot - > kexec can only multiboot Xen, *BSD) > or chainloader, I'll be happy. Our multiboot loader is very flexible, it can load _anywhere_, including its own heap, stack, code or data segments. However, not all payloads are prepared to accept any load address. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] trampoline for linux on 64-bit systems
On Sat, May 09, 2009 at 11:40:13AM +0200, Vladimir 'phcoder' Serbinenko wrote: > +++ b/loader/i386/efi/linux_trampoline.S Since this file is also used on loader/i386/linux.c, shouldn't it be moved above from efi/ ? -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] trampoline for linux on 64-bit systems
On Sat, May 09, 2009 at 11:40:13AM +0200, Vladimir 'phcoder' Serbinenko wrote: > Hello. On 64-bit systems the code may be loaded above 4GiB. When grub tries > to switch to 32-bit mode before launching linux it causes the reboot. Btw, I assume the problem happens with more than 4 GiB of physical memory? Does it affect the legacy loader as well? -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: status grub2 port of grub-legasy map command
On Sat, 2009-05-09 at 17:42 +0200, Javier Martín wrote: > OK, I have a good feeling about this version of the patch. Most > importantly, it still works!! I have committed your patch after a cleanup. My changes were following: grub_drivemap_int13_handler_base and grub_drivemap_int13_handler have been merged. grub_drivemap_int13_oldhandler points directly to the ljmp argument (other GRUB sources do it too, jump look for 0xea). %si is not used anymore. Tabs are used consistently in drivemap_int13h.S Many variables have been renamed. Constants have been brought to the top level and marked as such. Logic in uninstall_int13_handler() has been fixed. Some messages have been clarified. In particularly, biosdisk is called osdisk now, as it's what the OS sees. I was thinking of "payload" or "loadee" as more generic terms, but it can be confusing to the users. My check for drivemap with no arguments was wrong, fixed now. Added missing line ends in all outputs. Removed INT13H_REBASE and INT13H_TONEWADDR, as they were used only once. Comments have been improved. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub2 and fat efi files on latest Apples
Hi,
Thanks for the idea, here fat grub.efi tested ok on imac8,1 (64) and
MacBook2,1 (32), using working grub32.efi and grub64.efi with their
preloaded modules.
./fatglue.py grub2202f.efi grub2202-32.efi grub2202-64.efi
compile and fatglue were all done in OSX10.5.6.
Debian sid 2.6.29.1-amd64 boots for me on imac8,1 using
menuentry "sid amd64 fbdev sda9" {
fakebios
root=hd0,9
linux /vmlinuz root=/dev/sda9 video=efifb noefi
initrd /initrd.img
}
On Thu, May 14, 2009 at 1:35 AM, James Jarvis wrote:
> Newbie post but hopefully I will be providing some useful data rather than
> merely questions...
>
> I have been using the svn trunk over the last few days with some success
> compiling 32 and 64 bit EFI grub and creating a dual architecture grub.efi
> from the results that seems to work on hard disk on newer and older Apple
> Intel Macs. I use the fatglue.py python script from refit to make the fat
> grub.efi. Not sure if anyone else is doing anything similar...
>
> I have observed that fat modules don't work - need to use grub-mkimage to
> insert all the required modules.
>
> Another interesting observation (not really grub but maybe worth comment)
> is that using a Linux 2.6.29.2 kernel and initrd on the newer macs in efi
> mode boot (uses framebuffer console) works up until the insertion of
> modules. It appears that some modules do insert and other don't. The same
> kernel and initrd booted in "legacy mode" (after a call to fakebios) boots
> fine.
>
> Finally, the reboot call from linux on the iMac 9,1 hangs - possibly an
> issue with fakebios??? If the output of grub-dumpbios is any use let me
> know...
>
> Models tested (all intel)
>
> macmini
> iMac 4,1 requires ia32 or "fat" grub.efi
> iMac 8,1 requires x86_64 or "fat" grub.efi
> iMac 9,1 requires x86_64 or "fat" grub.efi
>
> James
>
>
>
>
>
>
>
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>
>
> ___
> 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: grub2 and fat efi files on latest Apples
Good to hear it is not just me finding it useful - certainly handy for
portable rescue media.
I take it there is no workaround (on Macs) for having a blessed hfsplus
filesystem with a blessed grub.efi - that is, on removable media
(usb/cd) for booting in efi mode (I know isolinux works fine in legacy
boot mode).
James
Peter Cros wrote:
Hi,
Thanks for the idea, here fat grub.efi tested ok on imac8,1 (64) and
MacBook2,1 (32), using working grub32.efi and grub64.efi with their
preloaded modules.
./fatglue.py grub2202f.efi grub2202-32.efi grub2202-64.efi
compile and fatglue were all done in OSX10.5.6.
Debian sid 2.6.29.1-amd64 boots for me on imac8,1 using
menuentry "sid amd64 fbdev sda9" {
fakebios
root=hd0,9
linux /vmlinuz root=/dev/sda9 video=efifb noefi
initrd /initrd.img
}
On Thu, May 14, 2009 at 1:35 AM, James Jarvis > wrote:
Newbie post but hopefully I will be providing some useful data
rather than merely questions...
I have been using the svn trunk over the last few days with some
success compiling 32 and 64 bit EFI grub and creating a dual
architecture grub.efi from the results that seems to work on hard
disk on newer and older Apple Intel Macs. I use the fatglue.py
python script from refit to make the fat grub.efi. Not sure if
anyone else is doing anything similar...
I have observed that fat modules don't work - need to use
grub-mkimage to insert all the required modules.
Another interesting observation (not really grub but maybe worth
comment) is that using a Linux 2.6.29.2 kernel and initrd on the
newer macs in efi mode boot (uses framebuffer console) works up
until the insertion of modules. It appears that some modules do
insert and other don't. The same kernel and initrd booted in
"legacy mode" (after a call to fakebios) boots fine.
Finally, the reboot call from linux on the iMac 9,1 hangs -
possibly an issue with fakebios??? If the output of grub-dumpbios
is any use let me know...
Models tested (all intel)
macmini
iMac 4,1 requires ia32 or "fat" grub.efi
iMac 8,1 requires x86_64 or "fat" grub.efi
iMac 9,1 requires x86_64 or "fat" grub.efi
James
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: status grub2 port of grub-legasy map command
Hello, I had two clear oppositions which weren't resolved. I don't
believe that merge patches screwing up the pendin oppositions is a
good practice. The opposition about declaration is based on another
handlers how it is used accross grub. Opposition about calling
biosdisk is technically relevant. Or perhaps I should start committing
anything without discussion?
Here is a fix patch. Could I commit it even if there will be oppositions?
On Thu, May 14, 2009 at 3:51 AM, Pavel Roskin wrote:
> On Sat, 2009-05-09 at 17:42 +0200, Javier Martín wrote:
>
>> OK, I have a good feeling about this version of the patch. Most
>> importantly, it still works!!
>
> I have committed your patch after a cleanup. My changes were following:
>
> grub_drivemap_int13_handler_base and grub_drivemap_int13_handler have
> been merged.
>
> grub_drivemap_int13_oldhandler points directly to the ljmp argument
> (other GRUB sources do it too, jump look for 0xea).
>
> %si is not used anymore.
>
> Tabs are used consistently in drivemap_int13h.S
>
> Many variables have been renamed.
>
> Constants have been brought to the top level and marked as such.
>
> Logic in uninstall_int13_handler() has been fixed.
>
Which logic fix?
Other than variable rename it seems to be identical to Javier Martín's patch
> Some messages have been clarified. In particularly, biosdisk is called
> osdisk now, as it's what the OS sees.
> I was thinking of "payload" or
> "loadee" as more generic terms, but it can be confusing to the users.
>
> My check for drivemap with no arguments was wrong, fixed now.
>
> Added missing line ends in all outputs.
>
> Removed INT13H_REBASE and INT13H_TONEWADDR, as they were used only once.
>
> Comments have been improved.
>
> --
> Regards,
> Pavel Roskin
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
--
Regards
Vladimir 'phcoder' Serbinenko
Index: commands/i386/pc/drivemap.c
===
--- commands/i386/pc/drivemap.c (revision 2213)
+++ commands/i386/pc/drivemap.c (working copy)
@@ -55,10 +55,10 @@
/* The assembly function to replace the old INT13h handler. It does not follow
any C callspecs and returns with IRET. */
-extern const void grub_drivemap_handler;
+extern const char grub_drivemap_handler[];
/* Start of the drive mappings area (space reserved at runtime). */
-extern const void grub_drivemap_mapstart;
+extern const char grub_drivemap_mapstart[];
typedef struct drivemap_node
{
@@ -74,7 +74,7 @@
} int13map_node_t;
#define INT13H_OFFSET(x) \
- (((grub_uint8_t *)(x)) - ((grub_uint8_t *)&grub_drivemap_handler))
+ ((x) - (grub_drivemap_handler))
static drivemap_node_t *map_head;
static void *drivemap_hook;
@@ -144,31 +144,6 @@
}
}
-/* Given a device name, resolves its BIOS disk number and stores it in the
- passed location, which should only be trusted if ERR_NONE is returned. */
-static grub_err_t
-parse_biosdisk (const char *name, grub_uint8_t *disknum)
-{
- grub_disk_t disk;
- /* Skip the first ( in (hd0) - disk_open wants just the name. */
- if (*name == '(')
-name++;
-
- disk = grub_disk_open (name);
- if (! disk)
-return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "unknown device \"%s\"",
- name);
- const enum grub_disk_dev_id id = disk->dev->id;
- /* The following assignment is only sound if the device is indeed a
- biosdisk. The caller must check the return value. */
- if (disknum)
-*disknum = disk->id;
- grub_disk_close (disk);
- if (id != GRUB_DISK_DEVICE_BIOSDISK_ID)
-return grub_error (GRUB_ERR_BAD_DEVICE, "%s is not a BIOS disk", name);
- return GRUB_ERR_NONE;
-}
-
/* Given a BIOS disk number, returns its GRUB device name if it exists.
If the call succeeds, the resulting device string must be freed.
For nonexisting BIOS disk numbers, this function returns
@@ -287,17 +262,14 @@
if (argc != 2)
return grub_error (GRUB_ERR_BAD_ARGUMENT, "two arguments required");
- err = parse_biosdisk (args[0], &mapfrom);
+ err = tryparse_diskstring (args[0], &mapfrom);
if (err != GRUB_ERR_NONE)
return err;
/* When swapping we require both devices to be BIOS disks, but when
performing direct mappings we only require the 2nd argument to look
like a BIOS disk in order to resolve it into a BIOS disk number. */
- if (cmd->state[OPTIDX_SWAP].set)
-err = parse_biosdisk (args[1], &mapto);
- else
-err = tryparse_diskstring (args[1], &mapto);
+ err = tryparse_diskstring (args[1], &mapto);
if (err != GRUB_ERR_NONE)
return err;
@@ -364,7 +336,7 @@
/* Find a rmode-segment-aligned zone in conventional memory big
enough to hold the handler and its data. */
- total_size = INT13H_OFFSET (&grub_drivemap_mapstart)
+ total_size = INT13H_OFFSET (grub_drivemap_mapstart)
+ (entries + 1) * sizeof (int13map_node_t);
grub_dprintf (MODNAME,
Re: status grub2 port of grub-legasy map command
On Thu, May 14, 2009 at 3:51 AM, Pavel Roskin wrote: > On Sat, 2009-05-09 at 17:42 +0200, Javier Martín wrote: > >> OK, I have a good feeling about this version of the patch. Most >> importantly, it still works!! > > I have committed your patch after a cleanup. My changes were following: > > grub_drivemap_int13_handler_base and grub_drivemap_int13_handler have > been merged. > > grub_drivemap_int13_oldhandler points directly to the ljmp argument > (other GRUB sources do it too, jump look for 0xea). > > %si is not used anymore. > > Tabs are used consistently in drivemap_int13h.S > > Many variables have been renamed. > > Constants have been brought to the top level and marked as such. > > Logic in uninstall_int13_handler() has been fixed. > > Some messages have been clarified. In particularly, biosdisk is called > osdisk now, as it's what the OS sees. I was thinking of "payload" or > "loadee" as more generic terms, but it can be confusing to the users. osdisk isn't less confusing than biosdisk. I already can see the users doing things like drivemap ata1 C: and asking why it fails. mapfrom and mapto are much better > > My check for drivemap with no arguments was wrong, fixed now. > > Added missing line ends in all outputs. > > Removed INT13H_REBASE and INT13H_TONEWADDR, as they were used only once. > > Comments have been improved. > > -- > Regards, > Pavel Roskin > > > ___ > 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
