macbook EFI experiences

macbook EFI experiences

[Isaac Dupree]

okay, I just tried a few days ago's grub2 CVS without patches for i386 
efi, because presumably if that doesn't work for me then nothing else 
will either (though it's possible that a working x86-64 would work 
better for this particular EFI firmware, I suppose)

I forget how I installed grub2-bios.  Is there a proper way to install 
grub2-efi that makes it know where all of its modules are so that I 
don't have to load them manually or include them in the .efi image?  I 
had to explicitly set `prefix=(hd0,3)/efi/grub` in order for `insmod 
(hd0,3)/efi/grub/linux.mod` to find the modules it depends on.  I think 
I might have just included *.mod in my grub2-bios image (which I put on 
a 200MB FAT partition) so that it would have any modules that might be 
needed in the future, configfile wouldn't need to be loaded explicitly, 
etc. etc. etc. (and I'm not sure how it finds that grub.cfg 
automatically either)... and yet I still have the individual modules 
copied around there for some (or no) reason.

Then the `linux` command worked... but `initrd` told me "error: no free 
pages available".  So I couldn't even get as far as loading the initrd 
(and `boot` after loading boot.mod, obviously didn't work since I need 
my initrd for Ubuntu).  Then if I tried to go back and `linux` again 
(say, because I needed to change the arguments to `linux`), it told me
"
cannot allocate pages
Aborted. Press any key to exit.
"
(And I pressed a key and it returned me to the rEFIt menu.)
A memory leak?  At that point, it shouldn't be using memory for the 
initrd because that never successfully loaded, and probably doesn't need 
the old linux when it's loading a new one.


The other thing I noticed is, while running grub2-efi, the fan goes on 
to max speed/noisyness.  (But grub2 isn't intended to be a huge fancy OS 
so there may be nothing reasonable to do about this.)


any advices?

-Isaac

Re: macbook EFI experiences

[Robert Millan]

On Fri, May 30, 2008 at 10:42:02AM -0400, Isaac Dupree wrote:
> okay, I just tried a few days ago's grub2 CVS without patches for i386 
> efi, because presumably if that doesn't work for me then nothing else 
> will either (though it's possible that a working x86-64 would work 
> better for this particular EFI firmware, I suppose)

Actually, I think it's better supported via grub-pc.  In BIOS we have a
workaround for the keyboard bug.  Was there any other kind of trouble?

> The other thing I noticed is, while running grub2-efi, the fan goes on 
> to max speed/noisyness.  (But grub2 isn't intended to be a huge fancy OS 
> so there may be nothing reasonable to do about this.)

Sounds like a firmware bug (busy polling for keyboard input).  Does this
device have an AT keyboard?  Our keyboard driver has the same bug, too, but
at least we can fix it ;-)

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: macbook EFI experiences

[Isaac Dupree]

Robert Millan wrote:
> On Fri, May 30, 2008 at 10:42:02AM -0400, Isaac Dupree wrote:
>> okay, I just tried a few days ago's grub2 CVS without patches for i386 
>> efi, because presumably if that doesn't work for me then nothing else 
>> will either (though it's possible that a working x86-64 would work 
>> better for this particular EFI firmware, I suppose)
> 
> Actually, I think it's better supported via grub-pc.  In BIOS we have a
> workaround for the keyboard bug.  Was there any other kind of trouble?

No it's not.  I can't use the keyboard on BIOS here, except sometimes 
for one single keystroke or more if I get lucky (true for linux CD 
booting, not just grub2); but the keyboard works fine on EFI and always 
has.  (Or was that workaround you mentioned in grub2 introduced sometime 
in the last year, in which case I should upgrade my grub2-bios 
installation?)

In any case I want to help debug grub2 efi to at least specify what 
still doesn't work, (if anything), even if the keyboard issue is fixed 
for bios.  Then the question becomes whether Ubuntu can survive being 
booted without the BIOS CSM enabled -- which I have yet to see, because 
I couldn't get elilo to work for me either.  But that's not the 
bootloader's problem, right? (although ideally it would be able to find 
a way to -- optionally -- enable the CSM, but I don't think a way has 
been found yet to enable it at all?)

> 
>> The other thing I noticed is, while running grub2-efi, the fan goes on 
>> to max speed/noisyness.  (But grub2 isn't intended to be a huge fancy OS 
>> so there may be nothing reasonable to do about this.)
> 
> Sounds like a firmware bug (busy polling for keyboard input).  Does this
> device have an AT keyboard?  Our keyboard driver has the same bug, too, but
> at least we can fix it ;-)

I have no idea what kind of keyboard it is... I know there's a built-in 
keyboard that I'm typing on, but I can't find it with `sudo lshw`, I 
can't think of anywhere more thorough to look, and Apple's specs don't 
seem to say <http://www.apple.com/macbook/specs.html>.  Plugging in an 
Apple USB keyboard was no better than the built-in one.

P.S. the bios-bootloader-keyboard failure is a well known Apple firmware 
bug that they claim to have fixed but it didn't seem fixed to me after I 
installed their firmware update


-Isaac

Re: macbook EFI experiences

[Bean]

On Sat, May 31, 2008 at 12:06 AM, Isaac Dupree
<id@isaac.cedarswampstudios.org> wrote:
> Robert Millan wrote:
>>
>> On Fri, May 30, 2008 at 10:42:02AM -0400, Isaac Dupree wrote:
>>>
>>> okay, I just tried a few days ago's grub2 CVS without patches for i386
>>> efi, because presumably if that doesn't work for me then nothing else will
>>> either (though it's possible that a working x86-64 would work better for
>>> this particular EFI firmware, I suppose)
>>
>> Actually, I think it's better supported via grub-pc.  In BIOS we have a
>> workaround for the keyboard bug.  Was there any other kind of trouble?
>
> No it's not.  I can't use the keyboard on BIOS here, except sometimes for
> one single keystroke or more if I get lucky (true for linux CD booting, not
> just grub2); but the keyboard works fine on EFI and always has.  (Or was
> that workaround you mentioned in grub2 introduced sometime in the last year,
> in which case I should upgrade my grub2-bios installation?)

This problem should be gone by now, try the cvs version ?

BTW, I think you should use bios if you can. I remember seeing some
post about the video driver needs video bios for initialization. In
pure EFI mode, it will fallback to frame buffer mode which is slower.
I don't know if this have been fixed by now.

-- 
Bean

Re: macbook EFI experiences

[Isaac Dupree]

Bean wrote:
> On Sat, May 31, 2008 at 12:06 AM, Isaac Dupree
> <id@isaac.cedarswampstudios.org> wrote:
>> Robert Millan wrote:
>>> On Fri, May 30, 2008 at 10:42:02AM -0400, Isaac Dupree wrote:
>>>> okay, I just tried a few days ago's grub2 CVS without patches for i386
>>>> efi, because presumably if that doesn't work for me then nothing else will
>>>> either (though it's possible that a working x86-64 would work better for
>>>> this particular EFI firmware, I suppose)
>>> Actually, I think it's better supported via grub-pc.  In BIOS we have a
>>> workaround for the keyboard bug.  Was there any other kind of trouble?
>> No it's not.  I can't use the keyboard on BIOS here, except sometimes for
>> one single keystroke or more if I get lucky (true for linux CD booting, not
>> just grub2); but the keyboard works fine on EFI and always has.  (Or was
>> that workaround you mentioned in grub2 introduced sometime in the last year,
>> in which case I should upgrade my grub2-bios installation?)
> 
> This problem should be gone by now, try the cvs version ?

okay, I guess I will try it

> BTW, I think you should use bios if you can. I remember seeing some
> post about the video driver needs video bios for initialization. In
> pure EFI mode, it will fallback to frame buffer mode which is slower.
> I don't know if this have been fixed by now.

It's fixed now for my hardware, Intel's new video driver in Xorg 7.3 
doesn't need any BIOS hacks or anything, I believe.  Anyway, I'll find 
out if it works just as soon as I manage to actually get into 
linux-kernel under EFI, so *if* it doesn't break, then I can keep using 
that and avoid (1) the unnecessary and potentially buggy CSM, (2) the 
hassles of installing a pc-bios-style bootloader on the header of one of 
my partitions. (and (3) be able to report bugs (in whatever software is 
affected) that happen later on when doing it that way.)  It can't hurt 
to try...

-Isaac

Re: macbook EFI experiences

[Robert Millan]

On Fri, May 30, 2008 at 12:29:59PM -0400, Isaac Dupree wrote:
> It's fixed now for my hardware, Intel's new video driver in Xorg 7.3 
> doesn't need any BIOS hacks or anything, I believe.  Anyway, I'll find 
> out if it works just as soon as I manage to actually get into 
> linux-kernel under EFI, so *if* it doesn't break, then I can keep using 
> that and avoid (1) the unnecessary and potentially buggy CSM, (2) the 
> hassles of installing a pc-bios-style bootloader on the header of one of 
> my partitions. (and (3) be able to report bugs (in whatever software is 
> affected) that happen later on when doing it that way.)  It can't hurt 
> to try...

You don't need to use the header of one of your partitions.  You can use
the MBR or even have a dedicated partition for core.img.  Then you can install
the rest of GRUB in a filesystem that's not case unsensitive! ;-P

Btw what's a CSM?

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: macbook EFI experiences

[Isaac Dupree]

Robert Millan wrote:
> On Fri, May 30, 2008 at 12:29:59PM -0400, Isaac Dupree wrote:
>> It's fixed now for my hardware, Intel's new video driver in Xorg 7.3 
>> doesn't need any BIOS hacks or anything, I believe.  Anyway, I'll find 
>> out if it works just as soon as I manage to actually get into 
>> linux-kernel under EFI, so *if* it doesn't break, then I can keep using 
>> that and avoid (1) the unnecessary and potentially buggy CSM, (2) the 
>> hassles of installing a pc-bios-style bootloader on the header of one of 
>> my partitions. (and (3) be able to report bugs (in whatever software is 
>> affected) that happen later on when doing it that way.)  It can't hurt 
>> to try...
> 
> You don't need to use the header of one of your partitions.  You can use
> the MBR or even have a dedicated partition for core.img.  Then you can install
> the rest of GRUB in a filesystem that's not case unsensitive! ;-P

I know, but I don't entirely understand how it works and I'd rather 
not... and it gives me limited options: theoretical maximum of 5 I 
think, 1 in MBR and 1 in each of first four partitions (each with their 
own hacks).  I much prefer being able to put as many .efi files as fit 
all on one partition, for refit to find.  As it is, when I upgrade GRUB, 
there always has to be the fear that I did something wrong that I can't 
easily fix because it's not just in the location of my files (it's 
hidden in mbr/partition headers), and because I can't boot into Linux 
anymore because I broke the bootloader :-)  It's been very lucky that I 
can so far always boot into OS X without going through GRUB, and edit my 
grub.cfg from there... That, and keeping 10.4 updated, are the two main 
reasons I ever boot into MacOS :-)

> Btw what's a CSM?

"Compatibility Support Modules", it's a name for the BIOS substitute 
that Apple added to EFI to support their "Boot Camp"/Windows.


Looking at the page http://refit.sourceforge.net/myths/ "Fact: You need 
BIOS compatibility for 2D/3D accelleration" (which hasn't been updated 
for a long time...) it looks like if I want the console (rather than X) 
to display anything, I'll still need video BIOS... good to know when 
testing to see if anything works

Re: macbook EFI experiences

[Robert Millan]

On Fri, May 30, 2008 at 05:01:51PM -0400, Isaac Dupree wrote:
> >
> >You don't need to use the header of one of your partitions.  You can use
> >the MBR or even have a dedicated partition for core.img.  Then you can 
> >install
> >the rest of GRUB in a filesystem that's not case unsensitive! ;-P
> 
> I know, but I don't entirely understand how it works and I'd rather 
> not... and it gives me limited options: theoretical maximum of 5 I 
> think, 1 in MBR and 1 in each of first four partitions (each with their 
> own hacks).

You're confusing BIOS-based boot with msdos partition labels.  You can use
GPT just fine when booting from BIOS (although Intel tries to hide that
fact by embedding the GPT spec inside the EFI spec).

> I much prefer being able to put as many .efi files as fit 
> all on one partition, for refit to find.  As it is, when I upgrade GRUB, 
> there always has to be the fear that I did something wrong that I can't 
> easily fix because it's not just in the location of my files (it's 
> hidden in mbr/partition headers), and because I can't boot into Linux 
> anymore because I broke the bootloader :-)  It's been very lucky that I 
> can so far always boot into OS X without going through GRUB, and edit my 
> grub.cfg from there... That, and keeping 10.4 updated, are the two main 
> reasons I ever boot into MacOS :-)

I think what we need here is to support MacOS boot from GRUB.  Then you
can use GRUB as your bootloader and don't need to use it as a piece of
glue between Refit and Linux..

Want to help us on that? :-)

> >Btw what's a CSM?
> 
> "Compatibility Support Modules", it's a name for the BIOS substitute 
> that Apple added to EFI to support their "Boot Camp"/Windows.

Notice that, like "EFI", "BIOS" doesn't imply any underliing implementation;
it just defines an interface (Intel uses this confusion to pretend their
firmware is free, when in fact only its shell -EFI- is).  Unless I missed
something, Apple's BIOS is as much a BIOS as is any other one.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

rename partmap/pc.c? (Re: macbook EFI experiences)

[Robert Millan]

On Sat, May 31, 2008 at 11:35:01AM +0200, Robert Millan wrote:
> 
> You're confusing BIOS-based boot with msdos partition labels.  You can use
> GPT just fine when booting from BIOS (although Intel tries to hide that
> fact by embedding the GPT spec inside the EFI spec).

Btw, maybe this hints that we don't have a very appropiate name for
partmap/pc.c.

Initially, GRUB assumed that i386-pc always wants 'pc' partmap; later it
was fixed to support BIOS-based boot on GPT.  As it stands, I don't think
it makes much sense to relate msdos labels with PC.  In the original PC
it was an OS issue after all, just like FAT, since BIOS just loaded the MBR
and didn't care what the partition layout were.

What would you all think about renaming to partmap/msdos.c ?

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: rename partmap/pc.c? (Re: macbook EFI experiences)

[Pavel Roskin]

On Sat, 2008-05-31 at 11:41 +0200, Robert Millan wrote:

> What would you all think about renaming to partmap/msdos.c ?

I don't like long names, as you might have noticed, but I think both
"pc" and "msdos" fail to convey the purpose of the module.  If we are
going to rename things, I would consider prefixing all partition table
support modules in some way, e.g. pt_msdos, pt_apple, pt_gpt etc.

-- 
Regards,
Pavel Roskin

Re: rename partmap/pc.c? (Re: macbook EFI experiences)

[Robert Millan]

On Sat, May 31, 2008 at 01:13:42PM -0400, Pavel Roskin wrote:
> On Sat, 2008-05-31 at 11:41 +0200, Robert Millan wrote:
> 
> > What would you all think about renaming to partmap/msdos.c ?
> 
> I don't like long names, as you might have noticed, but I think both
> "pc" and "msdos" fail to convey the purpose of the module.  If we are
> going to rename things, I would consider prefixing all partition table
> support modules in some way, e.g. pt_msdos, pt_apple, pt_gpt etc.

How about "part_" prefix?  It makes its meaning a bit clearer.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: rename partmap/pc.c? (Re: macbook EFI experiences)

[Pavel Roskin]

On Sun, 2008-06-01 at 12:23 +0200, Robert Millan wrote:
> On Sat, May 31, 2008 at 01:13:42PM -0400, Pavel Roskin wrote:
> > On Sat, 2008-05-31 at 11:41 +0200, Robert Millan wrote:
> > 
> > > What would you all think about renaming to partmap/msdos.c ?
> > 
> > I don't like long names, as you might have noticed, but I think both
> > "pc" and "msdos" fail to convey the purpose of the module.  If we are
> > going to rename things, I would consider prefixing all partition table
> > support modules in some way, e.g. pt_msdos, pt_apple, pt_gpt etc.
> 
> How about "part_" prefix?  It makes its meaning a bit clearer.

Fine with me.  Another possibility is "ptab_".  It's your choice.

-- 
Regards,
Pavel Roskin

Re: macbook EFI experiences

[Isaac Dupree]

Robert Millan wrote:
> On Fri, May 30, 2008 at 05:01:51PM -0400, Isaac Dupree wrote:
>>> You don't need to use the header of one of your partitions.  You can use
>>> the MBR or even have a dedicated partition for core.img.  Then you can 
>>> install
>>> the rest of GRUB in a filesystem that's not case unsensitive! ;-P
>> I know, but I don't entirely understand how it works and I'd rather 
>> not... and it gives me limited options: theoretical maximum of 5 I 
>> think, 1 in MBR and 1 in each of first four partitions (each with their 
>> own hacks).
> 
> You're confusing BIOS-based boot with msdos partition labels.  You can use
> GPT just fine when booting from BIOS (although Intel tries to hide that
> fact by embedding the GPT spec inside the EFI spec).

I have the hack which combines the two partition labels so I have both 
GPT and msdos labels.  Which means that my first four partitions (only) 
are listed in msdos, and GPT is the really accurate one that MacOS and 
Linux use.  However, I can't find a way to get into bootloader-land via 
BIOS without going through the msdos partitioning mechanism.

>> I much prefer being able to put as many .efi files as fit 
>> all on one partition, for refit to find.  As it is, when I upgrade GRUB, 
>> there always has to be the fear that I did something wrong that I can't 
>> easily fix because it's not just in the location of my files (it's 
>> hidden in mbr/partition headers), and because I can't boot into Linux 
>> anymore because I broke the bootloader :-)  It's been very lucky that I 
>> can so far always boot into OS X without going through GRUB, and edit my 
>> grub.cfg from there... That, and keeping 10.4 updated, are the two main 
>> reasons I ever boot into MacOS :-)
> 
> I think what we need here is to support MacOS boot from GRUB.  Then you
> can use GRUB as your bootloader and don't need to use it as a piece of
> glue between Refit and Linux..
> 
> Want to help us on that? :-)

that'd be nice... although I kind of like it how it is for me now, 
choosing Mac vs. GRUB in rEFIt, so I'm not *particularly* inspired to 
help :-)

>>> Btw what's a CSM?
>> "Compatibility Support Modules", it's a name for the BIOS substitute 
>> that Apple added to EFI to support their "Boot Camp"/Windows.
> 
> Notice that, like "EFI", "BIOS" doesn't imply any underliing implementation;
> it just defines an interface (Intel uses this confusion to pretend their
> firmware is free, when in fact only its shell -EFI- is).  Unless I missed
> something, Apple's BIOS is as much a BIOS as is any other one.

I think you're right about that.  (Except that I don't think that even 
the EFI part of the firmware is free on Apple computers, as far as I 
know they've done proprietary modifications to the free 
example-implementation and not been interested in releasing firmware 
sources.)

-Isaac

Re: macbook EFI experiences

[Robert Millan]

On Sat, May 31, 2008 at 02:57:21PM -0400, Isaac Dupree wrote:
> >
> >You're confusing BIOS-based boot with msdos partition labels.  You can use
> >GPT just fine when booting from BIOS (although Intel tries to hide that
> >fact by embedding the GPT spec inside the EFI spec).
> 
> I have the hack which combines the two partition labels so I have both 
> GPT and msdos labels.  Which means that my first four partitions (only) 
> are listed in msdos, and GPT is the really accurate one that MacOS and 
> Linux use.

I'm not sure if this would confuse GRUB partition-wise.  Can it access all
partitions?

> However, I can't find a way to get into bootloader-land via 
> BIOS without going through the msdos partitioning mechanism.

grub-setup may, too, be confused by this hack.  Saving that, you should be
able to install GRUB in MBR following the normal procedure, without any
need for msdos-style partition table (other than the dummy 0xee one).

Would be nice if you can verify GRUB works in both situations.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: macbook EFI experiences

[Bean]

On Sun, Jun 1, 2008 at 3:26 AM, Robert Millan <rmh@aybabtu.com> wrote:
> On Sat, May 31, 2008 at 02:57:21PM -0400, Isaac Dupree wrote:
>> >
>> >You're confusing BIOS-based boot with msdos partition labels.  You can use
>> >GPT just fine when booting from BIOS (although Intel tries to hide that
>> >fact by embedding the GPT spec inside the EFI spec).
>>
>> I have the hack which combines the two partition labels so I have both
>> GPT and msdos labels.  Which means that my first four partitions (only)
>> are listed in msdos, and GPT is the really accurate one that MacOS and
>> Linux use.
>
> I'm not sure if this would confuse GRUB partition-wise.  Can it access all
> partitions?
>

I'm not sure about your config, but recently, I install debian lenny
on my macbook, it kind of work OFTB. libparted support gpt, so no need
to use mbr at all. At the boot loader stage, I install grub2 to my
linux partition (hd0,3), then reboot. Refit is smart enough to
recognized my linux setup, and start grub from the boot menu. In
grub2, it actually uses gpt, I can access all the partitions from it.

-- 
Bean

Re: macbook EFI experiences

[Robert Millan]

On Sun, Jun 01, 2008 at 03:52:35AM +0800, Bean wrote:
> On Sun, Jun 1, 2008 at 3:26 AM, Robert Millan <rmh@aybabtu.com> wrote:
> > On Sat, May 31, 2008 at 02:57:21PM -0400, Isaac Dupree wrote:
> >> >
> >> >You're confusing BIOS-based boot with msdos partition labels.  You can use
> >> >GPT just fine when booting from BIOS (although Intel tries to hide that
> >> >fact by embedding the GPT spec inside the EFI spec).
> >>
> >> I have the hack which combines the two partition labels so I have both
> >> GPT and msdos labels.  Which means that my first four partitions (only)
> >> are listed in msdos, and GPT is the really accurate one that MacOS and
> >> Linux use.
> >
> > I'm not sure if this would confuse GRUB partition-wise.  Can it access all
> > partitions?
> >
> 
> I'm not sure about your config, but recently, I install debian lenny
> on my macbook, it kind of work OFTB. libparted support gpt, so no need
> to use mbr at all. At the boot loader stage, I install grub2 to my
> linux partition (hd0,3), then reboot. Refit is smart enough to
> recognized my linux setup, and start grub from the boot menu. In
> grub2, it actually uses gpt, I can access all the partitions from it.

You should be able to install GRUB to your MBR as well (GPT labels have an
MBR, which is "dummy" for partition table purposes but usable for boot
code).

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: macbook EFI experiences

[Isaac Dupree]

Robert Millan wrote:
> On Sat, May 31, 2008 at 02:57:21PM -0400, Isaac Dupree wrote:
>>> You're confusing BIOS-based boot with msdos partition labels.  You can use
>>> GPT just fine when booting from BIOS (although Intel tries to hide that
>>> fact by embedding the GPT spec inside the EFI spec).
>> I have the hack which combines the two partition labels so I have both 
>> GPT and msdos labels.  Which means that my first four partitions (only) 
>> are listed in msdos, and GPT is the really accurate one that MacOS and 
>> Linux use.
> 
> I'm not sure if this would confuse GRUB partition-wise.  Can it access all
> partitions?

yes, I was booting from the fifth partition for a while -- grub just 
needs the gpt module while running, obviously.  That disk layout is a 
standard hack, there are tools for it named e.g. "gptsync" that the 
rEFIt guys mention/include.

> 
>> However, I can't find a way to get into bootloader-land via 
>> BIOS without going through the msdos partitioning mechanism.
> 
> grub-setup may, too, be confused by this hack.  Saving that, you should be
> able to install GRUB in MBR following the normal procedure, without any
> need for msdos-style partition table (other than the dummy 0xee one).
> 
> Would be nice if you can verify GRUB works in both situations.

I bet it works fine that way too -- but I don't really have any way to 
get back to having just one dummy msdos-partition without wiping my 
disk, as far as I know.

-Isaac

Re: macbook EFI experiences

[Bean]

Hi,

The problem with initrd is that it can't allocate enough memory.
Please try the following patch, it will show some info that could be
be useful in debugging.

diff --git a/loader/i386/efi/linux.c b/loader/i386/efi/linux.c
index ee3fb99..327fcaf 100644
--- a/loader/i386/efi/linux.c
+++ b/loader/i386/efi/linux.c
@@ -619,6 +619,7 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
   if (grub_efi_get_memory_map (&mmap_size, mmap_buf, 0, &desc_size, 0) <= 0)
     grub_fatal ("cannot get memory map");

+  grub_printf ("%x %x %x\n", addr_min, addr_max, initrd_pages);
   addr = 0;
   for (desc = mmap_buf;
        desc < NEXT_MEMORY_DESCRIPTOR (mmap_buf, mmap_size);

-- 
Bean

Re: macbook EFI experiences

[Isaac Dupree]

Bean wrote:
> Hi,
> 
> The problem with initrd is that it can't allocate enough memory.
> Please try the following patch, it will show some info that could be
> be useful in debugging.

linux (hd0,4)/vmlinuz
     [Linux-EFI, setup=0x2a00, size=0x1d2798]
initrd (hd0,4)/initrd.img
   679000 1ffeffff 832

Re: macbook EFI experiences

[Bean]

On Wed, Jun 4, 2008 at 12:28 AM, Isaac Dupree
<id@isaac.cedarswampstudios.org> wrote:
> Bean wrote:
>>
>> Hi,
>>
>> The problem with initrd is that it can't allocate enough memory.
>> Please try the following patch, it will show some info that could be
>> be useful in debugging.
>
> linux (hd0,4)/vmlinuz
>    [Linux-EFI, setup=0x2a00, size=0x1d2798]
> initrd (hd0,4)/initrd.img
>  679000 1ffeffff 832

Hi,

I figure it out now, there is some problem with the initrd allocation
algorithm, the following patch should fix it:

diff --git a/loader/i386/efi/linux.c b/loader/i386/efi/linux.c
index ee3fb99..8d0e0c2 100644
--- a/loader/i386/efi/linux.c
+++ b/loader/i386/efi/linux.c
@@ -601,7 +604,7 @@ grub_rescue_cmd_initrd (int argc, char *argv[])

   lh = (struct linux_kernel_header *) real_mode_mem;

-  addr_max = grub_cpu_to_le32 (lh->initrd_addr_max);
+  addr_max = (grub_cpu_to_le32 (lh->initrd_addr_max) << 10);
   if (linux_mem_size != 0 && linux_mem_size < addr_max)
     addr_max = linux_mem_size;

@@ -612,7 +615,8 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
   addr_max -= 0x10000;

   /* Usually, the compression ratio is about 50%.  */
-  addr_min = (grub_addr_t) prot_mode_mem + ((prot_mode_pages * 3) << 12);
+  addr_min = (grub_addr_t) prot_mode_mem + ((prot_mode_pages * 3) << 12)
+     + page_align (size);

   /* Find the highest address to put the initrd.  */
   mmap_size = find_mmap_size ();
@@ -625,8 +629,6 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
        desc = NEXT_MEMORY_DESCRIPTOR (desc, desc_size))
     {
       if (desc->type == GRUB_EFI_CONVENTIONAL_MEMORY
-	  && desc->physical_start >= addr_min
-	  && desc->physical_start + size < addr_max
 	  && desc->num_pages >= initrd_pages)
 	{
 	  grub_efi_physical_address_t physical_end;
@@ -635,6 +637,9 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
 	  if (physical_end > addr_max)
 	    physical_end = addr_max;

+          if (physical_end  < addr_min)
+            continue;
+
 	  if (physical_end > addr)
 	    addr = physical_end - page_align (size);
 	}

-- 
Bean

Re: macbook EFI experiences

[Isaac Dupree]

how do you apply this patch?  With `patch -p1` I'm getting:
2 out of 4 hunks FAILED -- saving rejects to file 
loader/i386/efi/linux.c.rej

any more infos needed?
-Isaac

Bean wrote:
> Hi,
> 
> I figure it out now, there is some problem with the initrd allocation
> algorithm, the following patch should fix it:
> 
> diff --git a/loader/i386/efi/linux.c b/loader/i386/efi/linux.c
> index ee3fb99..8d0e0c2 100644
> --- a/loader/i386/efi/linux.c
> +++ b/loader/i386/efi/linux.c
> @@ -601,7 +604,7 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
> 
>    lh = (struct linux_kernel_header *) real_mode_mem;
> 
> -  addr_max = grub_cpu_to_le32 (lh->initrd_addr_max);
> +  addr_max = (grub_cpu_to_le32 (lh->initrd_addr_max) << 10);
>    if (linux_mem_size != 0 && linux_mem_size < addr_max)
>      addr_max = linux_mem_size;
> 
> @@ -612,7 +615,8 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
>    addr_max -= 0x10000;
> 
>    /* Usually, the compression ratio is about 50%.  */
> -  addr_min = (grub_addr_t) prot_mode_mem + ((prot_mode_pages * 3) << 12);
> +  addr_min = (grub_addr_t) prot_mode_mem + ((prot_mode_pages * 3) << 12)
> +     + page_align (size);
> 
>    /* Find the highest address to put the initrd.  */
>    mmap_size = find_mmap_size ();
> @@ -625,8 +629,6 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
>         desc = NEXT_MEMORY_DESCRIPTOR (desc, desc_size))
>      {
>        if (desc->type == GRUB_EFI_CONVENTIONAL_MEMORY
> -	  && desc->physical_start >= addr_min
> -	  && desc->physical_start + size < addr_max
>  	  && desc->num_pages >= initrd_pages)
>  	{
>  	  grub_efi_physical_address_t physical_end;
> @@ -635,6 +637,9 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
>  	  if (physical_end > addr_max)
>  	    physical_end = addr_max;
> 
> +          if (physical_end  < addr_min)
> +            continue;
> +
>  	  if (physical_end > addr)
>  	    addr = physical_end - page_align (size);
>  	}
> 

Re: macbook EFI experiences

[Bean]

On Wed, Jun 4, 2008 at 7:01 PM, Isaac Dupree
<id@isaac.cedarswampstudios.org> wrote:
> how do you apply this patch?  With `patch -p1` I'm getting:
> 2 out of 4 hunks FAILED -- saving rejects to file
> loader/i386/efi/linux.c.rej
>
> any more infos needed?

There maybe some code mixups, try this one:

BTW, are you using a customized kernel ? Some people reports that efi
booting don't work. They have 32-bit firmware just like yours, but
hangs even without the initrd.


diff --git a/loader/i386/efi/linux.c b/loader/i386/efi/linux.c
index ee3fb99..5ace7c0 100644
--- a/loader/i386/efi/linux.c
+++ b/loader/i386/efi/linux.c
@@ -601,7 +601,7 @@ grub_rescue_cmd_initrd (int argc, char *argv[])

   lh = (struct linux_kernel_header *) real_mode_mem;

-  addr_max = grub_cpu_to_le32 (lh->initrd_addr_max);
+  addr_max = (grub_cpu_to_le32 (lh->initrd_addr_max) << 10);
   if (linux_mem_size != 0 && linux_mem_size < addr_max)
     addr_max = linux_mem_size;

@@ -612,7 +612,8 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
   addr_max -= 0x10000;

   /* Usually, the compression ratio is about 50%.  */
-  addr_min = (grub_addr_t) prot_mode_mem + ((prot_mode_pages * 3) << 12);
+  addr_min = (grub_addr_t) prot_mode_mem + ((prot_mode_pages * 3) << 12)
+             + page_align (size);

   /* Find the highest address to put the initrd.  */
   mmap_size = find_mmap_size ();
@@ -625,8 +626,6 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
        desc = NEXT_MEMORY_DESCRIPTOR (desc, desc_size))
     {
       if (desc->type == GRUB_EFI_CONVENTIONAL_MEMORY
-	  && desc->physical_start >= addr_min
-	  && desc->physical_start + size < addr_max
 	  && desc->num_pages >= initrd_pages)
 	{
 	  grub_efi_physical_address_t physical_end;
@@ -635,6 +634,9 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
 	  if (physical_end > addr_max)
 	    physical_end = addr_max;

+          if (physical_end < addr_min)
+            continue;
+
 	  if (physical_end > addr)
 	    addr = physical_end - page_align (size);
 	}


-- 
Bean

Re: macbook EFI experiences

[Isaac Dupree]

Bean wrote:
> On Wed, Jun 4, 2008 at 7:01 PM, Isaac Dupree
> <id@isaac.cedarswampstudios.org> wrote:
>> how do you apply this patch?  With `patch -p1` I'm getting:
>> 2 out of 4 hunks FAILED -- saving rejects to file
>> loader/i386/efi/linux.c.rej
>>
>> any more infos needed?
> 
> There maybe some code mixups, try this one:

nope, against latest CVS:

 > patch -p1 <../grubinitrd2.patch
patching file loader/i386/efi/linux.c
Hunk #1 FAILED at 601.
Hunk #2 FAILED at 612.
2 out of 4 hunks FAILED -- saving rejects to file 
loader/i386/efi/linux.c.rej


> BTW, are you using a customized kernel ? Some people reports that efi
> booting don't work. They have 32-bit firmware just like yours, but
> hangs even without the initrd.

Well, I'll see what happens.  (Ubuntu kernel is very customized by the 
Ubuntu devs.)  I have a theory that the console display doesn't work so 
I need to get feedback some other way (X? Sound? File modification? 
Visibility on network (plug into ethernet first)?) to see if linux has 
booted.  Also once I have got this patch tried, I'll try adding your 
other patch(es) for x86-64 and see if a 64-bit EFI image makes any 
difference (although I doubt it will work any *better*, and possibly 
worse. but who knows.)

Does grub2 "multiboot"-ing itself, work yet? (just so we could test that 
too under EFI)

> 
> diff --git a/loader/i386/efi/linux.c b/loader/i386/efi/linux.c
> index ee3fb99..5ace7c0 100644
> --- a/loader/i386/efi/linux.c
> +++ b/loader/i386/efi/linux.c
> @@ -601,7 +601,7 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
> 
>    lh = (struct linux_kernel_header *) real_mode_mem;
> 
> -  addr_max = grub_cpu_to_le32 (lh->initrd_addr_max);
> +  addr_max = (grub_cpu_to_le32 (lh->initrd_addr_max) << 10);
>    if (linux_mem_size != 0 && linux_mem_size < addr_max)
>      addr_max = linux_mem_size;
> 
> @@ -612,7 +612,8 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
>    addr_max -= 0x10000;
> 
>    /* Usually, the compression ratio is about 50%.  */
> -  addr_min = (grub_addr_t) prot_mode_mem + ((prot_mode_pages * 3) << 12);
> +  addr_min = (grub_addr_t) prot_mode_mem + ((prot_mode_pages * 3) << 12)
> +             + page_align (size);
> 
>    /* Find the highest address to put the initrd.  */
>    mmap_size = find_mmap_size ();
> @@ -625,8 +626,6 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
>         desc = NEXT_MEMORY_DESCRIPTOR (desc, desc_size))
>      {
>        if (desc->type == GRUB_EFI_CONVENTIONAL_MEMORY
> -	  && desc->physical_start >= addr_min
> -	  && desc->physical_start + size < addr_max
>  	  && desc->num_pages >= initrd_pages)
>  	{
>  	  grub_efi_physical_address_t physical_end;
> @@ -635,6 +634,9 @@ grub_rescue_cmd_initrd (int argc, char *argv[])
>  	  if (physical_end > addr_max)
>  	    physical_end = addr_max;
> 
> +          if (physical_end < addr_min)
> +            continue;
> +
>  	  if (physical_end > addr)
>  	    addr = physical_end - page_align (size);
>  	}
> 
> 

Re: macbook EFI experiences

[Bean]

On Wed, Jun 4, 2008 at 7:27 PM, Isaac Dupree
<id@isaac.cedarswampstudios.org> wrote:
> Bean wrote:
>>
>> On Wed, Jun 4, 2008 at 7:01 PM, Isaac Dupree
>> <id@isaac.cedarswampstudios.org> wrote:
>>>
>>> how do you apply this patch?  With `patch -p1` I'm getting:
>>> 2 out of 4 hunks FAILED -- saving rejects to file
>>> loader/i386/efi/linux.c.rej
>>>
>>> any more infos needed?
>>
>> There maybe some code mixups, try this one:
>
> nope, against latest CVS:
>
>> patch -p1 <../grubinitrd2.patch
> patching file loader/i386/efi/linux.c
> Hunk #1 FAILED at 601.
> Hunk #2 FAILED at 612.
> 2 out of 4 hunks FAILED -- saving rejects to file
> loader/i386/efi/linux.c.rej

Use -l option in patch to ignore space. If it still not work, you can
make the changes manually, it's quite simple:

1)
   lh = (struct linux_kernel_header *) real_mode_mem;

-  addr_max = grub_cpu_to_le32 (lh->initrd_addr_max);
   if (linux_mem_size != 0 && linux_mem_size < addr_max)
     addr_max = linux_mem_size;

change the line to addr_max = (grub_cpu_to_le32 (lh->initrd_addr_max) << 10);

2)
   addr_max -= 0x10000;

   /* Usually, the compression ratio is about 50%.  */
-  addr_min = (grub_addr_t) prot_mode_mem + ((prot_mode_pages * 3) << 12);

   /* Find the highest address to put the initrd.  */
   mmap_size = find_mmap_size ();

change the line to
 addr_min = (grub_addr_t) prot_mode_mem + ((prot_mode_pages * 3) << 12)
                 + page_align (size);

3)

        desc = NEXT_MEMORY_DESCRIPTOR (desc, desc_size))
     {
       if (desc->type == GRUB_EFI_CONVENTIONAL_MEMORY
-	  && desc->physical_start >= addr_min
-	  && desc->physical_start + size < addr_max
 	  && desc->num_pages >= initrd_pages)
 	{
 	  grub_efi_physical_address_t physical_end;

Remove two lines.

4)
 	  if (physical_end > addr_max)
 	    physical_end = addr_max;

+          if (physical_end < addr_min)
+            continue;
+
 	  if (physical_end > addr)
 	    addr = physical_end - page_align (size);
 	}

Add three lines

-- 
Bean

Re: macbook EFI experiences

[Isaac Dupree]

Bean wrote:
> Use -l option in patch to ignore space. If it still not work, you can
> make the changes manually, it's quite simple:

/naive me thanks you for mentioning -l

> Ok, I can basically make everything else work, even chainloading OS X,
> but it just don't boot Linux. Kernel and initrd loads properly, but it
> hangs when boot. I start to wonder if this is the kernel's fault. I
> apply the patches from mactel-linux.org, not working either. And elilo
> also fails to load linux.

same here, initrd loading looks to be working properly now with your 
patch, and Linux seems to get equally stuck even when I boot a kernel 
that doesn't need/have an initrd (despite all with CONFIG_EFI=y, and 
other _EFI_ things on too; in particular, it wasn't on the network when 
I had ethernet cable plugged in, and it normally would be, so that's my 
evidence that it definitely didn't boot). (though I didn't try 
chainloading OSX).  So it seems your patches improve matters; but we're 
not in paradise yet :-), and may not be for a while, so the patches 
should probably go into grub and the symptoms documented?

-Isaac