Bug-fix elf.c powerpc ieee1275
Hi, There is a bug in /kern/elf.c/ (target powerpc, platform ieee1275), causing load linux to fail on my powerpc64 g5 and ibook g4 32bit. Here is a diff of the fix I found necessary for rev 1878 (bug has existed in previous versions). It was a one liner - diff -pu grubsvn/kern grubtry/kern/elf.c - --- grubsvn/kern/elf.c2008-09-28 17:27:56.0 +1000 +++ grubtry/kern/elf.c2008-09-28 23:16:38.0 +1000 @@ -234,7 +234,7 @@ grub_elf32_load (grub_elf_t _elf, grub_e if (load_hook && load_hook (phdr, &load_addr)) return 1; -load_addr = phdr->p_paddr; +/** pxwdebug - not required - load_addr = phdr->p_paddr; **/ if (load_addr < load_base) load_base = load_addr; @@ -413,8 +413,7 @@ grub_elf64_load (grub_elf_t _elf, grub_e if (load_hook && load_hook (phdr, &load_addr)) return 1; -load_addr = phdr->p_paddr; - +/**pxwdebug - not required - load_addr = phdr->p_paddr; **/ if (load_addr < load_base) load_base = load_addr; - pcros. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug-fix elf.c powerpc ieee1275
Explanation.
It seems to be a case of spurious line that got back into grub_elf32_load
and grub_elf64_load, nested function.
if (load_hook && load_hook (phdr, &load_addr))
return 1;
load_addr = phdr->p_paddr;
That sequence did not make sense to me, it overwrites the correct value of
load_addr from the preceding line.
Briefly -
with set debug=elf
Result -
for the bug -
..kernel/elf.c:429 Loading segment at 0x0 size 6ae0c8
fails to load kernel at 0x0 as expected.
the fix /* load_addr = phdr->p_paddr; */
..kernel/elf.c:429 Loading segment at 0x140 size 6ae0c8
loads kernel
--
Details -
Both 32bit ibook G4 and 64bit powerpc G5 were affected, and failed to load
linux kernel.
I rechecked and got some debug results to illustrate, hand copied from boot
screen.
I used grub_dprintf("elfpxw","phdr->p_paddr=%llx,
load_addr=%x\n",phdr->p_paddr,load_addr);
In grub_elf64_load as used by my powerpc64 g5.
The debugging outputs shown as they occur in sequence with the code (approx
line umbers)
if (load_hook && load_hook (phdr, &load_addr))
return 1;
..kernel/elf.c:421 phdr->p_paddr= c000 load_addr= 140
/* spurious line overwrites load_addr value from load_hook*/
load_addr = phdr->p_paddr;
..kernel/elf.c:424 phdr->p_paddr= c000 load_addr= 0
grub_dprintf ("elfpxw", "Loading segment at 0x%llx, size 0x%llx\n",
(unsigned long long) load_addr,
(unsigned long long) phdr->p_memsz);
..kernel/elf.c:429 Loading segment at 0x0 size 6ae0c8
- load kernel at 0x0 fails as expected
=
The correct result with /* load_addr = phdr->p_paddr;*/
if (load_hook && load_hook (phdr, &load_addr))
return 1;
phdr->p_paddr= c000 load_addr= 140
/*load_addr = phdr->p_paddr; */
phdr->p_paddr= c000 load_addr= 140
Loading segment at 0x140 size 6ae0c8
- load kernel at 0x140 succeeds.
=
peter cros.
On Mon, Sep 29, 2008 at 12:46 AM, Robert Millan <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 29, 2008 at 12:42:36AM +1000, peter cros wrote:
> > Hi,
> >
> > There is a bug in /kern/elf.c/ (target powerpc, platform ieee1275),
> > causing load linux to fail on my powerpc64 g5 and ibook g4 32bit.
> >
> > Here is a diff of the fix I found necessary for rev 1878 (bug has existed
> in
> > previous versions).
> >
> > It was a one liner -
> >
> > diff -pu grubsvn/kern grubtry/kern/elf.c
> > -
> > --- grubsvn/kern/elf.c2008-09-28 17:27:56.0 +1000
> > +++ grubtry/kern/elf.c2008-09-28 23:16:38.0 +1000
> > @@ -234,7 +234,7 @@ grub_elf32_load (grub_elf_t _elf, grub_e
> >
> > if (load_hook && load_hook (phdr, &load_addr))
> >return 1;
> > -load_addr = phdr->p_paddr;
> > +/** pxwdebug - not required - load_addr = phdr->p_paddr; **/
>
> Hi,
>
> Thanks for pointing this out. Unless someone understands your change,
> we'd need you to explain why this line isn't necessary, and why it was
> causing trouble.
>
> --
> 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
>
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug-fix elf.c powerpc ieee1275
The change was between svn version 1421 and 1509 which had bugfixes, in grub_elf32_load, and grub_elf64_load. [EMAIL PROTECTED]:~/src/grub$ diff -pu grub1421/kern/elf.c grub1509/kern/elf.c --- grub1421/kern/elf.c2008-09-30 14:49:46.0 +1000 +++ grub1509/kern/elf.c2008-09-30 14:41:31.0 +1000 @@ -228,9 +232,9 @@ grub_elf32_load (grub_elf_t _elf, grub_e if (phdr->p_type != PT_LOAD) return 0; -load_addr = phdr->p_paddr; if (load_hook && load_hook (phdr, &load_addr)) return 1; +load_addr = phdr->p_paddr; if (load_addr < load_base) load_base = load_addr; @@ -407,9 +411,9 @@ grub_elf64_load (grub_elf_t _elf, grub_e if (phdr->p_type != PT_LOAD) return 0; -load_addr = phdr->p_paddr; if (load_hook && load_hook (phdr, &load_addr)) return 1; +load_addr = phdr->p_paddr; if (load_addr < load_base) load_base = load_addr; ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug-fix elf.c powerpc ieee1275
Thanks for the explanation, but the bug has been a show stopper for
powerpc GNU-linux users trying to evaluate grub-ieee1275 since 1509,
and is still there in rev 1891.
Please can someone apply the reversion now?
On Tue, Sep 30, 2008 at 7:14 PM, Bean <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 30, 2008 at 3:26 PM, peter cros <[EMAIL PROTECTED]> wrote:
>> The change was between svn version 1421 and 1509 which had bugfixes,
>> in grub_elf32_load, and grub_elf64_load.
>
> Hi,
>
> The patch is for bsd loader, but it seems it uses the wrong method to
> change load address. This is the right patch:
>
> 2008-09-30 Bean <[EMAIL PROTECTED]>
>
>* kern/elf.c (grub_elf32_load): Revert to previous code.
>(grub_elf64_load): Likewise.
Yes confirmed that is the right patch for me running ubuntu linux on
an Apple G4 powerpc and G5 powerpc64, configuration using platform
=ieee1275, target=powerpc.
>
>* loader/i386/bsd.c (grub_bsd_elf32_hook): Change return address.
I can't comment on i386/bsd, I had not considered how other
platforms/targets might use different calls to
(grub_elf32_load)(grub_elf64_load).
>
> diff --git a/kern/elf.c b/kern/elf.c
> index 2b1e223..8ddf9e5 100644
> --- a/kern/elf.c
> +++ b/kern/elf.c
> @@ -232,9 +232,9 @@ grub_elf32_load (grub_elf_t _elf,
> grub_elf32_load_hook_t _load_hook,
> if (phdr->p_type != PT_LOAD)
> return 0;
>
> +load_addr = phdr->p_paddr;
> if (load_hook && load_hook (phdr, &load_addr))
> return 1;
> -load_addr = phdr->p_paddr;
>
> if (load_addr < load_base)
> load_base = load_addr;
> @@ -411,9 +411,9 @@ grub_elf64_load (grub_elf_t _elf,
> grub_elf64_load_hook_t _load_hook,
> if (phdr->p_type != PT_LOAD)
> return 0;
>
> +load_addr = phdr->p_paddr;
> if (load_hook && load_hook (phdr, &load_addr))
> return 1;
> -load_addr = phdr->p_paddr;
>
> if (load_addr < load_base)
> load_base = load_addr;
> diff --git a/loader/i386/bsd.c b/loader/i386/bsd.c
> index 4966afa..25d0f59 100644
> --- a/loader/i386/bsd.c
> +++ b/loader/i386/bsd.c
> @@ -454,7 +454,7 @@ grub_bsd_load_aout (grub_file_t file)
> }
>
> static grub_err_t
> -grub_bsd_elf32_hook (Elf32_Phdr * phdr, UNUSED grub_addr_t * addr)
> +grub_bsd_elf32_hook (Elf32_Phdr * phdr, grub_addr_t * addr)
> {
> Elf32_Addr paddr;
>
> @@ -472,6 +472,8 @@ grub_bsd_elf32_hook (Elf32_Phdr * phdr, UNUSED
> grub_addr_t * addr)
> if (paddr + phdr->p_memsz > kern_end)
> kern_end = paddr + phdr->p_memsz;
>
> + *addr = paddr;
> +
> return GRUB_ERR_NONE;
> }
>
> --
> Bean
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
peter cros
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: pager=1 as default? (Re: too many commands, "help" output rolls of screen)
Not yet, its not perfect just yet. For me on an apple efi macbook, pager=1 works very nicely on grub-efi (I did not know about it before), and can be unset, and it is great. But for grub ieee1275 on an apple ibookG4, it is useful, but has some erratic behaviour (garbling screen) and does not turn off with 'unset pager', so you don't want to be stuck with it. I don't know about grub-pc. On Mon, Nov 3, 2008 at 5:41 AM, Robert Millan <[EMAIL PROTECTED]> wrote: > Since this was intentional, I'd like to know what others (specially the > maintainers) think about this before proposing that it is changed... > > -- > 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 > peter cros ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Compilation PowerPC64
Also here on powerpc64 G5, after the recent change from grub_available_iterate() to grub_machine_mmap_iterate(). ... kernel_elf-kern_ieee1275_init.o: In function `grub_claim_heap': /home/pxw/src/grub2/build/../kern/ieee1275/init.c:182: undefined reference to `grub_machine_mmap_iterate' kernel_elf-symlist.o:(.data+0x38c): undefined reference to `grub_machine_mmap_iterate' collect2: ld returned 1 exit status make: *** [kernel.elf] Error 1 There is a separate startup memory bug for G5 powerpc64 with grub_available_iterate()/grub_machine_mmap_iterate() '#address-cells' incorrect interpretation for Apple G5, causing grub_claim_heap to fail and the [Welcome to Grub! out of memory], I want to recheck this and explain if still present. Peter Cros. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
G5 powerpc64 undefined reference to `grub_machine_mmap_iterate'
After Revision 1924 Harmonize ieee1275's grub_available_iterate() with the generic grub_machine_mmap_iterate() Attempting to make Rev 1928, configuration ieee1275 on G5 powerpc64 I am stuck with this error: kernel_elf-kern_ieee1275_init.o: In function `grub_claim_heap': /home/pxw/src/grub2/build/../kern/ieee1275/init.c:182: undefined reference to `grub_machine_mmap_iterate' kernel_elf-symlist.o:(.data+0x38c): undefined reference to `grub_machine_mmap_iterate' collect2: ld returned 1 exit status make: *** [kernel.elf] Error 1 I cant find it, would appreciate help. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: G5 powerpc64 undefined reference to `grub_machine_mmap_iterate'
Yes, thanks, I already ran the patch and checked the files, but still get the error. I will recheck, I may be doing something wrong here, but no compile problems before 1924 . I dont know if the machine could affect this, it is Apple powermac G5. On Sat, Nov 29, 2008 at 12:57 AM, Manoel Rebelo Abranches <[EMAIL PROTECTED]> wrote: > I have already sent a patch to correct this. > look at the email with subject [PATCH] Compilation PowerPC64. > It should work for you. > On Sat, 2008-11-29 at 00:12 +1100, peter cros wrote: >> After Revision 1924 >> Harmonize ieee1275's grub_available_iterate() with the generic >> grub_machine_mmap_iterate() >> >> Attempting to make Rev 1928, configuration ieee1275 on G5 powerpc64 I >> am stuck with this error: >> >> kernel_elf-kern_ieee1275_init.o: In function `grub_claim_heap': >> /home/pxw/src/grub2/build/../kern/ieee1275/init.c:182: undefined >> reference to `grub_machine_mmap_iterate' >> kernel_elf-symlist.o:(.data+0x38c): undefined reference to >> `grub_machine_mmap_iterate' >> collect2: ld returned 1 exit status >> make: *** [kernel.elf] Error 1 >> >> I cant find it, would appreciate help. >> >> >> ___ >> Grub-devel mailing list >> Grub-devel@gnu.org >> http://lists.gnu.org/mailman/listinfo/grub-devel > -- > Best Regards, > > Manoel Abranches <[EMAIL PROTECTED]> > IBM Linux Technology Center Brazil > > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > Peter Cros ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: G5 powerpc64 undefined reference to `grub_machine_mmap_iterate'
all fixed now thanks. On Sat, Nov 29, 2008 at 11:16 AM, peter cros <[EMAIL PROTECTED]> wrote: > Yes, thanks, I already ran the patch and checked the files, but still > get the error. I will recheck, I may be doing something wrong here, > but no compile problems before 1924 . I dont know if the machine could > affect this, it is Apple powermac G5. > > On Sat, Nov 29, 2008 at 12:57 AM, Manoel Rebelo Abranches > <[EMAIL PROTECTED]> wrote: >> I have already sent a patch to correct this. >> look at the email with subject [PATCH] Compilation PowerPC64. >> It should work for you. >> On Sat, 2008-11-29 at 00:12 +1100, peter cros wrote: >>> After Revision 1924 >>> Harmonize ieee1275's grub_available_iterate() with the generic >>> grub_machine_mmap_iterate() >>> >>> Attempting to make Rev 1928, configuration ieee1275 on G5 powerpc64 I >>> am stuck with this error: >>> >>> kernel_elf-kern_ieee1275_init.o: In function `grub_claim_heap': >>> /home/pxw/src/grub2/build/../kern/ieee1275/init.c:182: undefined >>> reference to `grub_machine_mmap_iterate' >>> kernel_elf-symlist.o:(.data+0x38c): undefined reference to >>> `grub_machine_mmap_iterate' >>> collect2: ld returned 1 exit status >>> make: *** [kernel.elf] Error 1 >>> >>> I cant find it, would appreciate help. >>> >>> >>> ___ >>> Grub-devel mailing list >>> Grub-devel@gnu.org >>> http://lists.gnu.org/mailman/listinfo/grub-devel >> -- >> Best Regards, >> >> Manoel Abranches <[EMAIL PROTECTED]> >> IBM Linux Technology Center Brazil >> >> >> >> ___ >> Grub-devel mailing list >> Grub-devel@gnu.org >> http://lists.gnu.org/mailman/listinfo/grub-devel >> > > Peter Cros > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: GRUB2 on efi32 - Apple Mac Mini
My current preferred bootloader is SVN version 1913 grub2.efi here on an Apple MacBook2,1. running Macosx10.4 and Ubuntu810 i386 32bit kernel (2.6.27 kernel), together with rEFIt 0.12 (but also used standalone). The amd64 kernel loaded but failed to complete initialization. Glad to know grub.efi still runs on the mini. To date I have not seen any reports of running on later MacBook versions. and the apple efi refused to load grub.efi on a macbook3,1. I have been trying to get Ubuntu forum people to test on other macs. I can comment on some of the issues mentioned. The rEFIt blesser resets to bless rEFIt on exit from Macosx. The explanation for this is on the rEFIt site. rEFIt has a case problem. The efi directory, containing grub.efi and refit.efi, needs to be upper case 'EFI' not 'efi', rEFIt confuses the case in the prefix passed to grub, hence loss of the grub.cfg menu. The failure to boot legacy bios may be associated with loss of MBR sector partitioning table (happens with the ubuntu linux parted partitioner for GPT/MBR disks). Check by a hexdump of the MBR sector. I can't get grub.efi to load rEFIt using chainloader, but I don't want to do that. I find considerable advantage over grub-pc is separate installation, off the linuix file system, and off the disk MBR sector, plus external drive bootability. Requirement to disable accelerated graphics is a stopper for some people. Pity it doesn't work on more macs. Peter Cros > > > ___ > 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 > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: EFI Boot on MacPro
Hi, The kernel vesion may be the bug there, I have found grub.efi needs 2.6.26 or later, configured with EFI enabled, else the result is similar to yours. I have had a grub.efi test package built from vesion 1913, running in ubuntuforums.com (apple intel) for a while, a number of people tried it. grub.efi it would load and run for Apple MacBook2,1, Apple mini2,1 MacBook pro 2,2 or earlier , i.e. none of the current Apple MacBooks, but no reports for Apple xserver, Imac or Mac Pro. It is therefore very interesting that grub.efi loads and runs on the Mac Pro, I would like to know what your the Model version is. peter cros On Wed, Jan 7, 2009 at 8:42 AM, Ziling Zhao wrote: > I'm trying to get grub2 working on a Mac Pro using pure EFI. > > So, I've mucked around a bit and grub is loading. I can have it load the > linux image as well, but it freezes soon after. > > Output is: > > Booting 'Gentoo' > > [Linux-bzImage, setup=0x2c00, size=0x2ff4701] > Video mode: 180x1050...@0 > Video frame buffer: f000 > > -- Then it freezes -- > > I seeded a bunch of grub_printf statements to see where it dies, and it > seems like it calls grub_machine_fini() (grub_loader_noreturn) is set to 1. > However, it doesn't seem to get back to grub_cmd_boot, which is calling > grub_loader_boot. > > Anybody know what this is doing? > > I've heard that people have successfully gotten non rEFItted makes to boot > Linux, can anybody confirm this? > > > I compiled the grub2 stuff with "./configure --with-platform=efi > --target=i386", this is grub trunk. > > > > -- > ~Ziling Zhao > > > > ___ > 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: EFI Boot on MacPro
On Wed, Jan 7, 2009 at 4:14 PM, Bean wrote: > On Wed, Jan 7, 2009 at 12:54 PM, peter cros wrote: > > Hi, > > > > The kernel vesion may be the bug there, I have found grub.efi needs > 2.6.26 > > or later, configured with EFI enabled, else the result is similar to > yours. > > > > I have had a grub.efi test package built from vesion 1913, running in > > ubuntuforums.com (apple intel) for a while, a number of people tried it. > > > > grub.efi it would load and run for Apple MacBook2,1, Apple mini2,1 > > MacBook pro 2,2 or earlier , i.e. none of the current Apple MacBooks, but > no > > reports for Apple xserver, Imac or Mac Pro. > > > > Later models have switched to 64-bit firmware, you need to use > x86_64-efi version of grub2. > > -- > Bean > > Thanks, I tried a --target =x86_64, using multilib, compiled on the > MacBook2,1 in i386, built OK, but could not run it on the macbook2,1. (I > dont have a later model ) > > So does that mean I need to build another package for x86_64 and put that > up for test on later version Mac, quite a few people interested, especially > for external drive booting. > > peter cros > > > ___ > 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: EFI Boot on MacPro
I am using ubuntu 810, kernel 2.6.27 no problem with grub.efi i386 MacBook2,1. On Wed, Jan 7, 2009 at 5:43 PM, Ziling Zhao wrote: > On Tuesday 06 January 2009 21:14:48 Bean wrote: > > On Wed, Jan 7, 2009 at 12:54 PM, peter cros wrote: > > > Hi, > > > > > > The kernel vesion may be the bug there, I have found grub.efi needs > > > 2.6.26 or later, configured with EFI enabled, else the result is > similar > > > to yours. > > > > > > I have had a grub.efi test package built from vesion 1913, running in > > > ubuntuforums.com (apple intel) for a while, a number of people tried > it. > > > > > > grub.efi it would load and run for Apple MacBook2,1, Apple mini2,1 > > > MacBook pro 2,2 or earlier , i.e. none of the current Apple MacBooks, > but > > > no reports for Apple xserver, Imac or Mac Pro. > > > > Later models have switched to 64-bit firmware, you need to use > > x86_64-efi version of grub2. > > Which models switched to 64bit firmware? Form the looks of it, all of them > are > still using EFI 1.x, does Grub2 support EFI 1.x with x86_64? > > I believe the kernel version that I am running is 2.6.27. > > I'll try again with the x86_64 version of Grub2 tomorrow. > > ~Ziling Zhao > > > ___ > 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: EFI Boot on MacPro
If not using refit, but using 'bless' from macosx - then grub.efi needs to be in an hfsplus partition on the usb stick. The built grub efi i386 tarball I use for macbook2,1 is on the ubuntu forum site, should suffice to show if you need x86_64. grub2 EFI boot loader http://ubuntuforums.org/showthread.php?t=995704 On Thu, Jan 8, 2009 at 12:34 AM, Türker SEZER wrote: > On Wednesday 07 January 2009 06:54:47 peter cros wrote: > > grub.efi it would load and run for Apple MacBook2,1, Apple mini2,1 > > MacBook pro 2,2 or earlier , i.e. none of the current Apple MacBooks, but > > no reports for Apple xserver, Imac or Mac Pro. > > I have a clean xserve 8-core. I havent installed any service on it, yet. So > i > can test grub2, x86_64-efi etc. > > I tried to use steps at http://grub.enbug.org/TestingOnEFI address. But > xserve > doesnt accept my usb stick as a bootable media. (at startup, i hold option > key, there is only my harddisks) > > If you tell me more way about testing grub2 on efi, i can do these tests. > > > Türker Sezer > > > ___ > 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: EFI Boot on MacPro
It all seems a bit strange, [Linux-bzImage, setup=0x2c00, size=0x2ff4701] Size=50 MB - very big kernel if it is true. On Fri, Jan 9, 2009 at 5:36 PM, Bean wrote: > On Fri, Jan 9, 2009 at 5:32 AM, Ziling Zhao wrote: > > I haven't had much success with testing directly on the XServe that I > have > > here, but I was able to get as far as getting grub to show up. However, > it > > stalls after: > > > > [Linux-bzImage, setup=0x2c00, size=0x2ff4701] > > Video mode: 180x1050...@0 > > Video frame buffer: f000 > > > > Just as far as I can get the Mac Pro. I don't exactly have a macbook to > test > > on, so I don't know if I'm just doing something wrong, or the Mac > > Pro/XServes are just different. Of course, using refit works on the mac > > pros, but applying the same process to the XServes didn't work. > > > > I've attached my .config just in case someone wants to look it over, I > > believe I have all the EFI stuff in there. > > Hi, > > The video mode line doesn't seem to be valid, so I guess xserver is > indeed different. > > Fedora also have efi loader, which is basically some hacking with grub > legacy. Perhaps you can try that and see if it works. > > -- > Bean > > > ___ > 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: EFI Boot on MacPro
iMac8,1 - grub.efi x86_64 hangs. built and run on the imac81 --with-platfrom=efi --target=x86_64 version 1913 and 1940 (current). Host ubuntu 810 amd64 kernel Linux im64 2.6.27-9-server #1 SMP Thu Nov 20 22:56:07 UTC 2008 x86_64 GNU/Linux grub.efi appears to be accepted by the firmware (started), but hangs immediately without any message. Tried with macosx bless, and with rEFIt, on HD and external usb. This differs from the 64/32 mismatch behaviour with the refit message 'unsupported while loading grub.efi') or the apple boot default to MacOSX. The x86_64 reult is different - bug in the start up? I will try to get some debug info. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: EFI Boot on MacPro
typo --with-platform=efi On Sun, Jan 11, 2009 at 1:44 PM, peter cros wrote: > iMac8,1 - grub.efi x86_64 hangs. > > built and run on the imac81 --with-platfrom=efi --target=x86_64 > version 1913 and 1940 (current). > > Host ubuntu 810 amd64 kernel Linux im64 2.6.27-9-server #1 SMP Thu Nov 20 > 22:56:07 UTC 2008 x86_64 GNU/Linux > > grub.efi appears to be accepted by the firmware (started), but hangs > immediately without any message. > Tried with macosx bless, and with rEFIt, on HD and external usb. > > This differs from the 64/32 mismatch behaviour with the refit message > 'unsupported while loading grub.efi') or the apple boot default to MacOSX. > > The x86_64 reult is different - bug in the start up? > > I will try to get some debug info. > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: EFI Boot on MacPro
It is here - (return checked in refit efi shell and gui)
Can't go any further until that is fixed.
kern/x86_64/efi/startup.S
---
This hangs -
codestart:
movq%rcx, EXT_C(grub_efi_image_handle)
movq%rdx, EXT_C(grub_efi_system_table)
+ret
callEXT_C(grub_main)
ret
-
This returns -
codestart:
+ret
movq%rcx, EXT_C(grub_efi_image_handle)
movq%rdx, EXT_C(grub_efi_system_table)
callEXT_C(grub_main)
ret
--
Would really like to see the solution for the imac8,1.
peter cros
On Sun, Jan 11, 2009 at 6:35 PM, Bean wrote:
> On Sun, Jan 11, 2009 at 10:44 AM, peter cros wrote:
> > iMac8,1 - grub.efi x86_64 hangs.
> >
> > built and run on the imac81 --with-platfrom=efi --target=x86_64
> > version 1913 and 1940 (current).
> >
> > Host ubuntu 810 amd64 kernel Linux im64 2.6.27-9-server #1 SMP Thu Nov 20
> > 22:56:07 UTC 2008 x86_64 GNU/Linux
> >
> > grub.efi appears to be accepted by the firmware (started), but hangs
> > immediately without any message.
> > Tried with macosx bless, and with rEFIt, on HD and external usb.
> >
> > This differs from the 64/32 mismatch behaviour with the refit message
> > 'unsupported while loading grub.efi') or the apple boot default to
> MacOSX.
> >
> > The x86_64 reult is different - bug in the start up?
> >
> > I will try to get some debug info.
>
> Hi,
>
> I only test the x86_64 version in macbook, which works nicely. Perhaps
> you can add some debug code in kern/main.c
>
> void
> grub_main (void)
> {
> /* First of all, initialize the machine. */
> grub_machine_init ();
>
> + grub_env_set ("debug", "all");
> + grub_printf ("init\n");
>
> /* Hello. */
> grub_setcolorstate (GRUB_TERM_COLOR_HIGHLIGHT);
> grub_printf ("Welcome to GRUB!\n\n");
> grub_setcolorstate (GRUB_TERM_COLOR_STANDARD);
>
>
> Also, the tsc code may has some effect, remove grub_tsc_init in
> kern/i366/efi/init.c:
>
> void
> grub_machine_init (void)
> {
> grub_efi_init ();
> -grub_tsc_init ();
> }
>
> --
> Bean
>
>
> ___
> 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: EFI Boot on MacPro
I tried your 64bit grub.efi, same result - hangs at start (on current
imac8,1).
I wonder if you have tested on the current MacBook or MacBook Pro, perhaps
Apple have made another change. Also I dont have any info on previous Imac
models.
I was able to get a return via grub_main() only by excluding both of the
movq lines in the code before the call. Either one hangs it.
Looks to be a problem with grub_efi_image_handle and grub_efi_system_table?
---
kern/x86_64/efi/startup.S
codestart:
callEXT_C(grub_main)
ret
-movq%rcx, EXT_C(grub_efi_image_handle)
-movq%rdx, EXT_C(grub_efi_system_table)
-
kern/main.c
void
grub_main (void)
{
return;
}
-
Is there anything else I can try?
peter cros
On Mon, Jan 12, 2009 at 4:04 AM, Bean wrote:
> On Mon, Jan 12, 2009 at 12:00 AM, peter cros wrote:
> > It is here - (return checked in refit efi shell and gui)
> > Can't go any further until that is fixed.
> >
> > kern/x86_64/efi/startup.S
> > ---
> >
> > This hangs -
> >
> > codestart:
> > movq%rcx, EXT_C(grub_efi_image_handle)
> > movq%rdx, EXT_C(grub_efi_system_table)
> > +ret
> > callEXT_C(grub_main)
> > ret
> > -
> >
> > This returns -
> >
> > codestart:
> > +ret
> > movq%rcx, EXT_C(grub_efi_image_handle)
> > movq%rdx, EXT_C(grub_efi_system_table)
> > callEXT_C(grub_main)
> > ret
> > --
> >
> > Would really like to see the solution for the imac8,1.
>
> Hi,
>
> This is quite strange, it might be caused by the compiler. You can try
> my version of grub.efi:
>
> http://grub4dos.sourceforge.net/grub.zip
>
> --
> Bean
>
>
> ___
> 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: EFI Boot on MacPro
Those numbers look better. Hanging at that stage can be due to incorrect boot command - trying to boot a kernel which requires an initrd. (not the only possibility). In my case I use - linux /vmlinuz root=/dev/sda3 video=efifb initrd /initrd.img If I try to boot without initrd I get your result. On Tue, Jan 13, 2009 at 7:06 AM, Ziling Zhao wrote: > On Fri, Jan 9, 2009 at 4:06 PM, peter cros wrote: > >> It all seems a bit strange, >> [Linux-bzImage, setup=0x2c00, size=0x2ff4701] >> Size=50 MB - very big kernel if it is true. >> >> >> On Fri, Jan 9, 2009 at 5:36 PM, Bean wrote: >> >>> On Fri, Jan 9, 2009 at 5:32 AM, Ziling Zhao >>> wrote: >>> > I haven't had much success with testing directly on the XServe that I >>> have >>> > here, but I was able to get as far as getting grub to show up. However, >>> it >>> > stalls after: >>> > >>> > [Linux-bzImage, setup=0x2c00, size=0x2ff4701] >>> > Video mode: 180x1050...@0 >>> > Video frame buffer: f000 >>> > >>> > Just as far as I can get the Mac Pro. I don't exactly have a macbook to >>> test >>> > on, so I don't know if I'm just doing something wrong, or the Mac >>> > Pro/XServes are just different. Of course, using refit works on the mac >>> > pros, but applying the same process to the XServes didn't work. >>> > >>> > I've attached my .config just in case someone wants to look it over, I >>> > believe I have all the EFI stuff in there. >>> >>> Hi, >>> >>> The video mode line doesn't seem to be valid, so I guess xserver is >>> indeed different. >>> >>> Fedora also have efi loader, which is basically some hacking with grub >>> legacy. Perhaps you can try that and see if it works. >>> >>> -- >>> Bean >>> >>> >>> ___ >>> 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 >> >> > I've just checked the kernel's size, and nothing is 50MB. > > After fiddling, now it says. (for x86 kernel) 3.5MB > > [Linux-bzImage, setup=0x3000, size=0x367f70] > Video mode: 1280x1024...@0 > Video frame buffer: f000 > > The x86_64 kernel has: > > [Linux-bzImage, setup=0x2c00, size=0x2ff470] > Video mode: 1280x1024...@0 > Video frame buffer: f000 > > > -- > ~Ziling Zhao > > > ___ > 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: grub2 on MacBook4,1
Hi, I have the same results on different Apple Macs - hung after the refit boot screen "Starting grub.efi ". ( Stops in startup.S ) grub2 rev 1952 --with-platform=efi --target=x86_64 MacBook Pro 4,1 Boot ROM Version: MBP41.00C1.B03 SMC Version: 1.28f1 GeForce 8600M GT Vendor: NVIDIA (0x10de) Resolution: 1920 x 1200 - iMac8,1 Boot ROM Version: IM81.00C1.B00 SMC Version: 1.30f ATI Radeon HD 2600 Pro Vendor: ATI (0x1002) Resolution: 1920 x 1200 The same build runs on earlier 64bit EFI Macbooks. (with other problems later booting kernel ). Peter Cros On Fri, Jan 30, 2009 at 10:42 PM, wrote: > > Hi, > I tried grub2 rev 1962 on my > MacBook4,1 > Boot ROM Version:MB41.00C1.B00 > SMC Version:1.31f0 > > I copied grub.efi mod files to grub folder in efi folder (I use refit 0.12) > When I select start from grub.efi I'm unable to get grub prompt > because it stop to "starting grub.efi" without any messages > > Thanks > Davide > > -- > check out the rest of the Windows Live™. More than mail–Windows Live™ goes > way beyond your inbox. More than > messages<http://www.microsoft.com/windows/windowslive/> > > ___ > 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
grub.efi x86_64 on Apple 64bit efi models - status of testing
I have got to a standstill with this, some major stoppers found and could
use some help to debug further. I hope someone can take a look at this
please, its getting beyond my limited C code reading and hacking
capabilities, but I do want to see grub.efi working on current Apple Intel
Macs.
Apple Linux/OSX users can benefit from grub.efi major advantages over the
Apple pc-bios emulation which cannot boot external drives and has other
installation problems for Linux users. Apple Mac users multi-booting
GNU/Linux and Mac OSX are a good testing ground for EFI booting. A number of
people in the ubuntuforums have tested grub.efi x86 and x86_64 on Apple
intel Macs from intel core2duo on. There have also been some recent reported
problems posted on grub-devel list.
I have not seen anything for IA32/64 machines.
>From early 2008, Macs have been using 64bit EFI, needing x86_64 grub.efi,
and I have posted on ubuntuforums a full x86_64 grub.efi package with all
modules and grub.cfg for people to try.
No one has been able to get x86_64 grub.efi to boot and run either Mac OSX
(boot.efi) or ubuntu 810 2.6.27 kernels (configured for EFI). All this works
well for x86 grub.efi on Intel Macs with the earlier 32 bit firmware.
---
Three specific issues are stopping useful testing -
1. Mac models from imac8,1 early 2008 are unable to boot grub.efi 64bit when
4GB RAM is fitted.
Dropping to 2GB RAM enables grub.efi to boot and display grub.cfg menu
with fully functional command line. This leads to the next problems -
2. The grub.efi chainloader command fails to load
/usr/standalone/i386/boot.efi, reporting ' error: cannot load image '
3. grub.efi successfully loads ubuntu x86 2.6.7-7 kernel ( or earlier debian
2.6.26 ) using command line or menuentry, but the boot fails.
After boot command, the boot screen goes to black and no further progress
seen,
except in one case some garbled video indicating possible boot but failure
to init.
4. Finally, there was a problem getting ubuntu 810 amd64 to complete
initialization after booting in earlier 32 bit grub.efi tests, and other
issues with accelerated graphics and keyboard. - Not yet the issue here.
-
I got as far as locating the area in the grub2 code as shown in the attached
diffs of commented files, and will continue to look throught the code, or
can try any suggested debugging. I have some access to an Imac8,1 MacBook
Pro 4,1 and a MacBook2,1.
( So far using set debug=all or selective, grub_printf(); grub_getkey();
asm volatile ("ret" : : ); )
But I am not a programmer and need help to go further. The x86 32 bit
grub.efi functions very well on MacBook2,1 and other earlier 32 bit EFI
Apples, but the later models need the x86_64 build, and at present it is not
functional at all. The Apple firmware and EFI seems to need special
treatment.
-
Diffs - ( these are just grub2 rev 1972 commented 'pxwdebug' to show where I
got to )
Diff 1. Failing to run grub.efi with 4GB RAM.
grub2 r=1972
--- grub2a/kern/x86_64/efi/startup.S2009-02-04 17:04:14.0 +1100
+++ grub2b/kern/x86_64/efi/startup.S2009-02-09 18:19:32.0 +1100
@@ -57,10 +57,12 @@ VARIABLE(grub_prefix)
codestart:
movq%rcx, EXT_C(grub_efi_image_handle)
movq%rdx, EXT_C(grub_efi_system_table)
+/*pxwdebug - with 4GB RAM, startup hangs before the call */
+
callEXT_C(grub_main)
ret
-
Diff 2. Failure of efi chainloader for Mac OSX
grub2 r=1972
--- grub2a/loader/efi/chainloader.c2009-02-04 17:04:22.0 +1100
+++ grub2b/loader/efi/chainloader.c2009-02-09 17:50:35.0 +1100
@@ -253,21 +253,21 @@ grub_rescue_cmd_chainloader (int argc, c
if (grub_errno == GRUB_ERR_NONE)
grub_error (GRUB_ERR_BAD_OS, "too small");
goto fail;
}
-
+/* pxwdebug macosx 10.4 10.5 fail to load with grub.efi x86_64 */
status = efi_call_6 (b->load_image, 0, grub_efi_image_handle, file_path,
(void *) ((grub_addr_t) address), size,
&image_handle);
if (status != GRUB_EFI_SUCCESS)
{
if (status == GRUB_EFI_OUT_OF_RESOURCES)
grub_error (GRUB_ERR_OUT_OF_MEMORY, "out of resources");
else
grub_error (GRUB_ERR_BAD_OS, "cannot load image");
-
+/*pxwdebug error message is "cannot load image" */
goto fail;
}
---
Diff 3. efi Linux boot fails.
grub2 r=1972
--- grub2a/loader/i386/efi/linux.c2009-02-04 17:04:22.0 +1100
+++ grub2b/loader/i386/efi/linux.c2009-02-09 18:09:22.0 +1100
@@ -419,19 +419,19 @@ grub_linux_boot (void)
asm volatile ("cli" : : );
/* Load the IDT and the GDT for the bootstrap. */
asm volatile ("lidt %0" : : "m" (idt_desc));
asm volatile ("lgdt %0" : : "m" (gdt_desc));
-
+/*pxwdebug x86_64 linux boot fails */
#ifdef __x86_64__
jumpvector.kernel_entry = (grub_uint64_t) grub_linux_real_boot;
jump
Re: grub_machine_fini on efi systems
There is also a problem with Apple 64 bit grub.efi booting ubuntu 2.6.27 linux in which the kernel is booted and starting but all video is lost after the boot command. I don't know if there may be a connection. A temporary fix is to change Video frame buufer settings in /loader/i386/efi/linux.c: grub_find_video_card and grub_linux_setup_video Then proceeds to the next bug (libata hangup during initrd ). On Tue, Feb 17, 2009 at 9:53 AM, phcoder wrote: > Hello. I found a serious problem which may be the cause of linux not > booting on some efi systems. grub_machine_fini is called before > grub_linux_boot. grub_machine_fini returns all memory allocated by grub2 to > efi. This includes all memory used to load modules. So actually efi can > rightfully destroy linux module before it has slightest chance to do its > job. I asked step21 to declare linux boot as returnable to stop > grub_machine_fini. However it's nothing more then a workaround. I hope that > someone will find a way to fix this nicely because for the moment I see > none. (perhaps tomorrow I'll find sth) > Regards > Vladimir 'phcoder' Serbinenko > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > -- Cros ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub_machine_fini on efi systems
1. Initially - With 2GB RAM Imac8,1 has 256MB VRAM Radeon HD2600 1920x1200 MBP4,1 has 512MB VRAM Nvidia 8600 1920x1200 Imac8,1 grub boot linux shows Video frame buffer at 9052 and blank screen. MBP4,1 gives 9000 and scrambled video. 2. By overriding video_base to set it at 2GB grub_linux_setup_video () video_base = 0; grub_pci_iterate (grub_find_video_card); /* override */ video_base = 0x8000; Result - MBP gets readable text screens from kernel boot and init. Imac gets scrambled video (better than nothing) 3. further fiddling with grub_linux_setup_video() params->lfb_line_len = 8192; changed fromm 8192 to = width*4 gets clear script for Imac, but MBP wants 8192. 4. The results with 4GB RAM will differ I expect, and later effects unknown as the linux initialization is not completing (other issues with libata). On Tue, Feb 17, 2009 at 2:02 PM, Bean wrote: > On Tue, Feb 17, 2009 at 10:56 AM, Peter Cros wrote: > > There is also a problem with Apple 64 bit grub.efi booting ubuntu 2.6.27 > > linux in which the kernel is booted and starting but all video is lost > after > > the boot command. I don't know if there may be a connection. > > A temporary fix is to change Video frame buufer settings in > > /loader/i386/efi/linux.c: > > grub_find_video_card and grub_linux_setup_video > > Then proceeds to the next bug (libata hangup during initrd ). > > Hi, > > What's your frame buffer address, does grub_find_video_card detect it wrong > ? > > -- > Bean > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > -- Cros ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub_machine_fini on efi systems
Update - with Imac8,1 booting linux now with 4GB RAM, the linux load video settings shown for 4GB RAM (with blank boot linux video screen) are now Video mode 1920x1200 - 3...@60 Video frame buffer: d052( was 0x9052 for 2GB RAM ) The VFB value needs changing again, when I have the source update to enable running with 4GB. On Tue, Feb 17, 2009 at 4:01 PM, Peter Cros wrote: > 1. Initially - With 2GB RAM > > Imac8,1 has 256MB VRAM Radeon HD2600 1920x1200 > MBP4,1 has 512MB VRAM Nvidia 8600 1920x1200 > > Imac8,1 grub boot linux shows Video frame buffer at 9052 and blank > screen. > > MBP4,1 gives 9000 and scrambled video. > > 2. By overriding video_base to set it at 2GB > > grub_linux_setup_video () > > video_base = 0; > grub_pci_iterate (grub_find_video_card); > /* override */ > video_base = 0x8000; > > Result - > MBP gets readable text screens from kernel boot and init. > Imac gets scrambled video (better than nothing) > > 3. further fiddling with > grub_linux_setup_video() > > params->lfb_line_len = 8192; > changed fromm 8192 to = width*4 gets clear script for Imac, but MBP wants > 8192. > > 4. The results with 4GB RAM will differ I expect, and later effects unknown > as the linux initialization is not completing (other issues with libata). > > > On Tue, Feb 17, 2009 at 2:02 PM, Bean wrote: > >> On Tue, Feb 17, 2009 at 10:56 AM, Peter Cros wrote: >> > There is also a problem with Apple 64 bit grub.efi booting ubuntu 2.6.27 >> > linux in which the kernel is booted and starting but all video is lost >> after >> > the boot command. I don't know if there may be a connection. >> > A temporary fix is to change Video frame buufer settings in >> > /loader/i386/efi/linux.c: >> > grub_find_video_card and grub_linux_setup_video >> > Then proceeds to the next bug (libata hangup during initrd ). >> >> Hi, >> >> What's your frame buffer address, does grub_find_video_card detect it >> wrong ? >> >> -- >> Bean >> >> >> ___ >> Grub-devel mailing list >> Grub-devel@gnu.org >> http://lists.gnu.org/mailman/listinfo/grub-devel >> > > > > -- > Cros > -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] bug fix for x86_64 efi
Tested the patch applied to rev 1996 for grub.efi 64 bit and 32 bit, on Imac81 (4GB ram), MacBookPro41 (4GB and 2GB ram) MacBook21 (i386) with Macosx 10.4 10.5, ubuntu810. All good. 64bit Macs have other ongoing EFI problems with linux kernel initializtion and keyboard. On Fri, Feb 20, 2009 at 2:12 AM, Bean wrote: > Hi, > > This patch contains several important update for x86_64 efi: > > 1, Support memory larger than 2G. > 2, Fix a bug in efi_call_6 that could cause chainloadering osx to fail. > 3, Improve the method to detect frame buffer address and line length > in linux loader. > > 2009-02-19 Bean > >* configure.ac: Check for -mcmodel=large in x86_64 target. > >* include/grub/efi/api.h (efi_call_10): New macro. >(efi_wrap_10): New function. > >* include/grub/efi/pe32.h (GRUB_PE32_REL_BASE_HIGH): New macro. >(GRUB_PE32_REL_BASED_HIGH): Likewise. >(GRUB_PE32_REL_BASED_LOW): Likewise. >(GRUB_PE32_REL_BASED_HIGHLOW): Likewise. >(GRUB_PE32_REL_BASED_HIGHADJ): Likewise. >(GRUB_PE32_REL_BASED_MIPS_JMPADDR): Likewise. >(GRUB_PE32_REL_BASED_SECTION): Likewise. >(GRUB_PE32_REL_BASED_REL): Likewise. >(GRUB_PE32_REL_BASED_IA64_IMM64): Likewise. >(GRUB_PE32_REL_BASED_DIR64): Likewise. >(GRUB_PE32_REL_BASED_HIGH3ADJ): Likewise. > >* kern/x86_64/dl.c (grub_arch_dl_relocate_symbols): Fixed relocation >issue. > >* kern/x86_64/efi/callwrap.S (efi_wrap_6): Bug fix. >(efi_wrap_10): New function. > >* kern/x86_64/efi/startup.S (codestart): Use relative addressing. > >* loader/efi/appleloader.c (devpath_5): Add support for late 2008 >MB/MBP model (NV chipset). >(devdata_devs): Add devpath_5 to the list. > >* load/i386/efi/linux.c (video_base): Remove variable. >(RGB_MASK): New macro. >(RGB_MAGIC): Likewise. >(LINE_MIN): Likewise. >(LINE_MAX): Likewise. >(FBTEST_STEP): Likewise. >(FBTEST_COUNT): Likewise. >(fb_list): New variable. >(grub_find_video_card): Remove function. >(find_framebuf): New function. >(grub_linux_setup_video): Use find_framebuf to get frame buffer and >line length. > >* util/i386/efi/grub-mkimage.c (grub_reloc_section): Fix relocation >problem for x86_64. > > -- > Bean > > ___ > 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: [PATCH] bug fix for x86_64 efi
I am just a grub.efi user/tester/enthusiast. I don't know the Xserve but some previous reports in this list of people getting grub.efi to boot on Xserve, and if so it will boot hd/usb linux on other Apple intel Macs with varying results . There are some grub.efi 64/32 bit test packages on ubuntuforums that you might try (include the patch) . Xserve results would be interesting. grub2 EFI boot loader internal/external booting<http://ubuntuforums.org/showthread.php?t=995704> On Sat, Feb 21, 2009 at 3:16 AM, Drew Rosen wrote: > Hi Peter / phcoder / all other grub gurus, > I've joined the grub-devel mail list while attempting to get MacIntel > Xserves to boot linux. I work with a 3d Movie Effects company that has 25 > MacIntel Xserves that are becoming close to as useful as paperweights > because they can't run Maya at 64bit for rendering. (and we can't repurpose > them as linux servers). > > Any chance we can help test this patch in an xserve environment, and/or do > you have any ideas that would help us? > > Here's the most discouraging info I've received in my research to date: > > The Xserve does not have BIOS compatibility, and so you'll need to boot > through EFI. The Apple EFI implementation will not boot directly off ISO9660 > media, so you'll need to find a way to get to the EFI console. You'll need a > kernel configured with EFI support. There's no especially sensible way to > get a working framebuffer on this hardware, so you'll need to work out what > arguments need to be passed to your distribution's installer in order to get > it to run over the serial port. elilo or grub-efi should be able to boot the > kernel and initramfs. > > I've been catologing my research at: > http://drewsta.com/xserve.html > > Thanks! > > Drew > > > > On Feb 20, 2009, at 6:28 AM, Peter Cros wrote: > > Tested the patch applied to rev 1996 for grub.efi 64 bit and 32 bit, on > Imac81 (4GB ram), MacBookPro41 (4GB and 2GB ram) MacBook21 (i386) > with Macosx 10.4 10.5, ubuntu810. > All good. > > 64bit Macs have other ongoing EFI problems with linux kernel initializtion > and keyboard. > > > On Fri, Feb 20, 2009 at 2:12 AM, Bean wrote: > >> Hi, >> >> This patch contains several important update for x86_64 efi: >> >> 1, Support memory larger than 2G. >> 2, Fix a bug in efi_call_6 that could cause chainloadering osx to fail. >> 3, Improve the method to detect frame buffer address and line length >> in linux loader. >> >> 2009-02-19 Bean >> >>* configure.ac: Check for -mcmodel=large in x86_64 target. >> >>* include/grub/efi/api.h (efi_call_10): New macro. >>(efi_wrap_10): New function. >> >>* include/grub/efi/pe32.h (GRUB_PE32_REL_BASE_HIGH): New macro. >>(GRUB_PE32_REL_BASED_HIGH): Likewise. >>(GRUB_PE32_REL_BASED_LOW): Likewise. >>(GRUB_PE32_REL_BASED_HIGHLOW): Likewise. >>(GRUB_PE32_REL_BASED_HIGHADJ): Likewise. >>(GRUB_PE32_REL_BASED_MIPS_JMPADDR): Likewise. >>(GRUB_PE32_REL_BASED_SECTION): Likewise. >>(GRUB_PE32_REL_BASED_REL): Likewise. >>(GRUB_PE32_REL_BASED_IA64_IMM64): Likewise. >>(GRUB_PE32_REL_BASED_DIR64): Likewise. >>(GRUB_PE32_REL_BASED_HIGH3ADJ): Likewise. >> >>* kern/x86_64/dl.c (grub_arch_dl_relocate_symbols): Fixed >> relocation >>issue. >> >>* kern/x86_64/efi/callwrap.S (efi_wrap_6): Bug fix. >>(efi_wrap_10): New function. >> >>* kern/x86_64/efi/startup.S (codestart): Use relative addressing. >> >>* loader/efi/appleloader.c (devpath_5): Add support for late 2008 >>MB/MBP model (NV chipset). >>(devdata_devs): Add devpath_5 to the list. >> >>* load/i386/efi/linux.c (video_base): Remove variable. >>(RGB_MASK): New macro. >>(RGB_MAGIC): Likewise. >>(LINE_MIN): Likewise. >>(LINE_MAX): Likewise. >>(FBTEST_STEP): Likewise. >>(FBTEST_COUNT): Likewise. >>(fb_list): New variable. >>(grub_find_video_card): Remove function. >>(find_framebuf): New function. >>(grub_linux_setup_video): Use find_framebuf to get frame buffer and >>line length. >> >>* util/i386/efi/grub-mkimage.c (grub_reloc_section): Fix relocation >>problem for x86_64. >> >> -- >> Bean >> >> ___ >> 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 > > > > ___ > 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: [PATCH] bug fix for x86_64 efi
Hi, True we don't have any grub.efi Apple intel Xserve hardware tests so far, at the apple intel ubuntu forum, but the grub-efi test packages there could be used to test. Seems you will need to get some current grub.efi test result to point to problems specific to the Xserve, sufficient to attract help at developer level. There are also some graphics limitations (use of framebuffer driver) after EFI linux booting for other intel macs, might be important for your application. On Sun, Feb 22, 2009 at 2:16 PM, Drew Rosen wrote: > Thanks for your interest in helping Peter. At first look, the ubuntu forum > looks like we're seeing xserver info, but no one using MacIntel Xserve > hardware to test grub. If you know anyone who could help us push thru what > is causing the Xserve to not work like the MacIntel Mac Pro Desktops, I'M > LOOKING FOR THAT PERSON... > Cheers. > > > On Feb 20, 2009, at 9:32 PM, Peter Cros wrote: > > I am just a grub.efi user/tester/enthusiast. > > I don't know the Xserve but some previous reports in this list of people > getting grub.efi to boot on Xserve, and if so it will boot hd/usb linux on > other Apple intel Macs with varying results . > > There are some grub.efi 64/32 bit test packages on ubuntuforums that you > might try (include the patch) . Xserve results would be interesting. > > grub2 EFI boot loader internal/external > booting<http://ubuntuforums.org/showthread.php?t=995704> > > > On Sat, Feb 21, 2009 at 3:16 AM, Drew Rosen wrote: > >> Hi Peter / phcoder / all other grub gurus, >> I've joined the grub-devel mail list while attempting to get MacIntel >> Xserves to boot linux. I work with a 3d Movie Effects company that has 25 >> MacIntel Xserves that are becoming close to as useful as paperweights >> because they can't run Maya at 64bit for rendering. (and we can't repurpose >> them as linux servers). >> >> Any chance we can help test this patch in an xserve environment, and/or do >> you have any ideas that would help us? >> >> Here's the most discouraging info I've received in my research to date: >> >> The Xserve does not have BIOS compatibility, and so you'll need to boot >> through EFI. The Apple EFI implementation will not boot directly off ISO9660 >> media, so you'll need to find a way to get to the EFI console. You'll need a >> kernel configured with EFI support. There's no especially sensible way to >> get a working framebuffer on this hardware, so you'll need to work out what >> arguments need to be passed to your distribution's installer in order to get >> it to run over the serial port. elilo or grub-efi should be able to boot the >> kernel and initramfs. >> >> I've been catologing my research at: >> http://drewsta.com/xserve.html >> >> Thanks! >> >> Drew >> >> >> >> On Feb 20, 2009, at 6:28 AM, Peter Cros wrote: >> >> Tested the patch applied to rev 1996 for grub.efi 64 bit and 32 bit, on >> Imac81 (4GB ram), MacBookPro41 (4GB and 2GB ram) MacBook21 (i386) >> with Macosx 10.4 10.5, ubuntu810. >> All good. >> >> 64bit Macs have other ongoing EFI problems with linux kernel initializtion >> and keyboard. >> >> >> On Fri, Feb 20, 2009 at 2:12 AM, Bean wrote: >> >>> Hi, >>> >>> This patch contains several important update for x86_64 efi: >>> >>> 1, Support memory larger than 2G. >>> 2, Fix a bug in efi_call_6 that could cause chainloadering osx to fail. >>> 3, Improve the method to detect frame buffer address and line length >>> in linux loader. >>> >>> 2009-02-19 Bean >>> >>>* configure.ac: Check for -mcmodel=large in x86_64 target. >>> >>>* include/grub/efi/api.h (efi_call_10): New macro. >>>(efi_wrap_10): New function. >>> >>>* include/grub/efi/pe32.h (GRUB_PE32_REL_BASE_HIGH): New macro. >>>(GRUB_PE32_REL_BASED_HIGH): Likewise. >>>(GRUB_PE32_REL_BASED_LOW): Likewise. >>>(GRUB_PE32_REL_BASED_HIGHLOW): Likewise. >>>(GRUB_PE32_REL_BASED_HIGHADJ): Likewise. >>>(GRUB_PE32_REL_BASED_MIPS_JMPADDR): Likewise. >>>(GRUB_PE32_REL_BASED_SECTION): Likewise. >>>(GRUB_PE32_REL_BASED_REL): Likewise. >>>(GRUB_PE32_REL_BASED_IA64_IMM64): Likewise. >>>(GRUB_PE32_REL_BASED_DIR64): Likewise. >>>(GRUB_PE32_REL_BASED_HIGH3ADJ): Likewise. >>> >>>* kern/x86_64/dl.c (grub_arch_dl_rel
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 wrote: > On 2009-03-10, Grant Edwards 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
I have used a separate small hfs+ partition, works well, and fast if blessed. The EFI FAT32 partition is OK and a good backup if using rEFIt to recognise it without needing to bless, but cant be blessed --folder. On Thu, Mar 12, 2009 at 9:51 AM, Grant Edwards wrote: > On 2009-03-11, phcoder wrote: > > Grant Edwards wrote: > >> On 2009-03-11, Grant Edwards wrote: > >> > >>> Moving grub from the EFI FAT32 partition to the HFS+ partition > >>> eliminates the 30-second delay. In this case the status looks > >>> like this: > >> > >> It's usable this way except it would be nice to have grub in a > >> second parition. That way if I break grub, I can still hold > >> down the option key and select the OS-X HFS+ partition. > > > > You can always format an additional HFS+ partition > > That sounds like something worth trying. We don't know if it's > working because it's in an HFS+ partition or if it's working > because it's in the same parition as OS-X. > > Maybe I'll stick in a USB flash drive with a GPT partition > table and an HFS+ partition. > > -- > Grant Edwards grante Yow! -- I love KATRINKA > at because she drives a > visi.comPONTIAC. We're going > away now. I fed the cat. > > > > ___ > 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
A brief read of the mininmyth docs suggests it can also run on a fat partition on the gpt hard disk. You can put an hfs+ partition on a msdos disk, or a fat32 partition on a gpt disk and grub.efi can handle both. plus linux ext2/3. Have you installed the rEFIt boot manager http://refit.sourceforge.net/ It simplifies testing and the web site has good information on Apple efi booting and some history. You need to read the Mac OSX bless manual closely to compare the options, and experiment. Seems to me the key issue is getting your kernel and system running, identity any grub development issues, the other stuff can be optimised later. My experience has been with other users of Apple Intel Macs bootng Debian/Ubuntu linux and Mac OSX, using grub-pc and grub-efi. It helps to have a linux installation on the hard drive. On Fri, Mar 13, 2009 at 1:37 AM, Grant Edwards wrote: > On 2009-03-12, Peter Cros wrote: > > > I have used a separate small hfs+ partition, works well, and > > fast if blessed. > > I think that's what I'll try next. > > The other option I'd like to try is a GPT-partitioned USB flash > drive. For that to be advantageous, I would need to add GPT > partition table support to my Linux kernel to avoid having to > plug in a second USB flash drive for the MiniMyth files. > > [The goal of the exercise is to use a Mac Mini as a "diskless" > MythTv frontend using the distro from www.minimyth.org. This > Mini is my first Mac since the 68k days, and I'm very impressed > with the hardware, but the firmware seems mediocre at best.] > > > The EFI FAT32 partition is OK and a good backup if using rEFIt > > to recognise it without needing to bless, but cant be blessed > > --folder. > > That's what I'd more-or-less concluded. I tried blessing the > device (/dev/disk0s1) and that didn't make any difference > either. > > What's odd is that I found step-by-step instructions that > specifically show booting elilo from the EFI partition on an > Intel Mac Mini at > > http://www.mythic-beasts.com/resources/macmini/walkthrough.html > > Did other versions of firmware allow blessing the EFI partition > somehow? > > -- > Grant Edwards grante Yow! Now I understand > the > at meaning of "THE MOD > SQUAD"! > 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
grub.efi booting from hfsplus on external msdos usb drive has worked for me, maybe I was usiing rEFIt. On Sat, Mar 14, 2009 at 4:20 AM, phcoder wrote: > Apple says that booting from msdos partition is unsupported, however I've > reports of people successfully doing so > Grant Edwards wrote: > >> On 2009-03-13, phcoder wrote: >> >> Have you tried booting from hfs+ on msdos? >>> >> >> Actually I haven't. I found multiple postings in various >> places saying that Mac firmware would only boot from USB drives >> if they were GPT partitioned, so I never bothered to try it. >> >> I'll give that a try as well. >> >> > > -- > > Regards > Vladimir 'phcoder' Serbinenko > > > > ___ > 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 Sat, Mar 14, 2009 at 1:26 AM, Grant Edwards wrote: > 1) Mac firmware not being able to boot from anything other > than an HFS+ partion on a GPT partioned drive. > I got curious and rechecked this - Here is grub.efi booting from usb msdos drive with hfsplus partition - sh-3.2# diskutil list /dev/disk1 /dev/disk1 #: TYPE NAMESIZE IDENTIFIER 0: FDisk_partition_scheme*1.9 Gi disk1 1: Linux 1.2 Gi disk1s1 2: Apple_HFS disk1s2 572.6 Mi disk1s2 3: DOS_FAT_32 fat32 100.4 Mi disk1s3 sh-3.2# bless --folder /Volumes/disk1s2 --file /Volumes/disk1s2/grub64.efi --label "msdoshfsp" --setBoot sh-3.2# bless --info /Volumes/disk1s2 finderinfo[0]: 2 => Blessed System Folder is /Volumes/disk1s2/ finderinfo[1]: 85 => Blessed System File is /Volumes/disk1s2/grub64.efi finderinfo[2]: 0 => Open-folder linked list empty finderinfo[3]: 0 => No OS 9 + X blessed 9 folder finderinfo[4]: 0 => Unused field unset finderinfo[5]: 2 => OS X blessed folder is /Volumes/disk1s2/ 64-bit VSDB volume id: 0x795006DDA23084CA sh-3.2# --setBoot gives deafult fast boot to grub menu, but when booted that way, grub can only see its own disk (hd0) If booted via Option key or rEFIt all drives are seen and bootable. > > 2) MiniMyth kernel lacks support for EFI/GPT parition tables > and SATA hard drives. > On the GPT drive, an MSDOS partition table is generated from gpt tables by the Mac OSX Bootcamp utility which creates a fat32 partition for the Windows msdos compatible mode. Or the msdos MBR can also be checked and generated by rEFIt (used by apple intel linux users). The list of drivers for minimyth seems to include those used for sata on my macs, but you may have better info. ___ > 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
Don't know, rechecked it here and it sees all the usb partitions whichever way its booted, maybe something wrong with your grub.efi build preloaded modules. Check the latest svn. On Sun, Mar 22, 2009 at 8:30 AM, Grant Edwards wrote: > On 2009-03-14, Peter Cros wrote: > > On Sat, Mar 14, 2009 at 1:26 AM, Grant Edwards wrote: > > > >> 1) Mac firmware not being able to boot from anything other > >> than an HFS+ partion on a GPT partioned drive. > > > > I got curious and rechecked this - > > Here is grub.efi booting from usb msdos drive with hfsplus partition - > > When I try that, I get one of two things: > > 1) When it boots directly into grub, grub can only see hd0 >(which appears to be the USB drive), but it can't see any >of the paritions on hd0. Needless to say, it can't find >it's config file. > > 2) Holding down the Option key and selecting grub allows it to >see both disks -- it can see partitions on the >GPT-partitioned hard drive but not on the MS-DOS >partitioned USB drive. I can manually load a config-file >from the hard drive, none of the menu entries work -- I see >stuff like > > error: unknown command `initrd' > > or > > error: unkown command `search' > > Here's the info on the USB drive: > > bash-3.2# diskutil list /dev/disk1 > /dev/disk1 > #: TYPE NAMESIZE > IDENTIFIER > 0: FDisk_partition_scheme*3.7 Gi disk1 > 1: DOS_FAT_32 minimyth1.9 Gi disk1s1 > 2: Apple_HFS mmhfs 1.9 Gi disk1s2 > > bash-3.2# bless --info /Volumes/mmhfs > finderinfo[0]: 2 => Blessed System Folder is /Volumes/mmhfs/ > finderinfo[1]:120 => Blessed System File is > /Volumes/mmhfs/efi/grub/grub.efi > finderinfo[2]: 0 => Open-folder linked list empty > finderinfo[3]: 0 => No OS 9 + X blessed 9 folder > finderinfo[4]: 0 => Unused field unset > finderinfo[5]: 2 => OS X blessed folder is /Volumes/mmhfs/ > 64-bit VSDB volume id: 0xA3FBF66150DE9BB1 > > > --setBoot gives deafult fast boot to grub menu, but when booted that way, > > grub can only see its own disk (hd0) > > Same here, and it can't see any of the partitions on that disk. > > End result: still no luck booting from USB drive, just a larger > variety of failure modes. > > -- > Grant > > > > > ___ > 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: [PATCH] New frame buffer detection algorithm and loadrom command for efi platform
Hi,
svn rev 2043 patched loadrom.diff on imac81 with ati fglrx.
I find loadrom needs time when called in menuentry, otherwise linux load
fails or loadrom fails. So I had to use sleep.
Then it works very nicely.
--
insmod sleep
menuentry "loadrom hd0,4 sda4" {
search --set /ivt.bin
loadrom /bios.bin /ivt.bin
sleep 1
root=hd0,4
linux /vmlinuz root=/dev/sda4 video=vesafb
initrd /initrd.img
}
This is not apparent from command line with manual entry pauses.
-
2009/3/21 Bean
> Hi,
>
> This patch improves the frame buffer detection algorithm. It uses pci
> to find the video memory base, then scan it for frame buffer.
>
> It also add a loadrom command which can be used to enable accel
> graphic driver. The idea is that you can grab the video bios dump, and
> optionally the IVT from pc mode, then load them in efi.
>
> To grab bios dump:
> sudo dd if=/dev/mem of=bios.bin bs=65536 skip=12 count=1
>
> You can also include the system bios by changing the count to 4.
>
> To grab IVT dump:
> sudo dd if=/dev/mem of=ivt.bin bs=1024 count=1
>
> Then, to load them in grub-efi (ivt.bin is optionally):
> loadrom /bios.bin /ivt.bin
>
> Here are some of the findings concerning different video cards:
>
> Old 32-bit efi model, intel card:
> Works with intel driver, no need to load vbios or ivt.
>
> New 64-bit efi model, intel card:
> Works with intel driver, needs to load vbios.
>
> New 64-bit efi model, nvidia card:
> Works with nvidia driver, no needs to load vbios or ivt. However, the
> backlight value is set too low so desktop is barely visible. You need
> to use a small tool to adjust backlight. The nv driver doesn't work.
>
> New 64-bit efi model, ati radeon card:
> Works with fglrx driver, needs to load vbios and ivt. The radeonhd
> driver doesn't work.
>
> --
> Bean
>
> ___
> 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: no commit allowed under discussion
Hi, It will be good to get this resolved and on SVN grub2 so people (ubuntuforums) can build for Apple efi with the latest 'hacks' (fakebios, loadbios etc) found necessary in testing. Particlarly Xserve which requires efi boot. On 4/7/09, Bean wrote: > On Tue, Apr 7, 2009 at 8:37 AM, Yoshinori K. Okuji wrote: >> On Tuesday 07 April 2009 01:43:17 Bean wrote: >>> On Sat, Apr 4, 2009 at 8:53 PM, Bean wrote: >>> > On Sat, Apr 4, 2009 at 5:30 PM, Yoshinori K. Okuji >> wrote: >>> >> I've undone r2063, since we're still discussing how to / not to split >>> >> modules. Bean, you must respect teamwork. If you are unable to follow >>> >> such a fundamental rule, I will have to disable your permission. >>> > >>> > Hi, >>> > >>> > I thought the previous mail is about replacing grub_printf with >>> > grub_dprint, I'm ok with that. This patch has been in mail list for >>> > sometime, it is essential to get a working display in intel macs. >>> >>> Hi, >>> >>> How about this patch ? The split is necessary as it introduces new >>> command loadbios and fakebios that uses the fake_bios_data function, >>> and it would be ugly to put them all inside linux.c. >> >> Do you have any strong reason to make loadbios and fakebios separate? I >> think >> the overhead is negligible. > > Hi, > > loadbios and fakebios are sort of like hacks for the efi platform, I > think they shouldn't be placed in the linux loader. Also, by moving > the platform dependent code out, we can merge it with i386 generic > loader loader/i386/linux.c. > > -- > Bean > > > ___ > 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: no commit allowed under discussion
Hi, SVN rev 2074 should be good for Xserve1,1 and 1,2 according to tests we ran at ubuntu forums. On Tue, Apr 14, 2009 at 6:23 PM, Drew Rosen wrote: > Hi Peter Cros, > > If you need anyone to run tests on the Xserve, I have a score of machines > that we want to use on Linux... > > > > > On Apr 9, 2009, at 7:23 AM, Peter Cros wrote: > > Hi, >> It will be good to get this resolved and on SVN grub2 so people >> (ubuntuforums) can build for Apple efi with the latest 'hacks' >> (fakebios, loadbios etc) found necessary in testing. Particlarly >> Xserve which requires efi boot. >> >> >> On 4/7/09, Bean wrote: >> >>> On Tue, Apr 7, 2009 at 8:37 AM, Yoshinori K. Okuji >>> wrote: >>> >>>> On Tuesday 07 April 2009 01:43:17 Bean wrote: >>>> >>>>> On Sat, Apr 4, 2009 at 8:53 PM, Bean wrote: >>>>> >>>>>> On Sat, Apr 4, 2009 at 5:30 PM, Yoshinori K. Okuji >>>>>> >>>>> wrote: >>>> >>>>> I've undone r2063, since we're still discussing how to / not to split >>>>>>> modules. Bean, you must respect teamwork. If you are unable to follow >>>>>>> such a fundamental rule, I will have to disable your permission. >>>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> I thought the previous mail is about replacing grub_printf with >>>>>> grub_dprint, I'm ok with that. This patch has been in mail list for >>>>>> sometime, it is essential to get a working display in intel macs. >>>>>> >>>>> >>>>> Hi, >>>>> >>>>> How about this patch ? The split is necessary as it introduces new >>>>> command loadbios and fakebios that uses the fake_bios_data function, >>>>> and it would be ugly to put them all inside linux.c. >>>>> >>>> >>>> Do you have any strong reason to make loadbios and fakebios separate? I >>>> think >>>> the overhead is negligible. >>>> >>> >>> Hi, >>> >>> loadbios and fakebios are sort of like hacks for the efi platform, I >>> think they shouldn't be placed in the linux loader. Also, by moving >>> the platform dependent code out, we can merge it with i386 generic >>> loader loader/i386/linux.c. >>> >>> -- >>> Bean >>> >>> >>> ___ >>> 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 >> > > > > ___ > 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: no commit allowed under discussion
I posted binaries from grub2 rev 2074 with all modules, for further evaluation - http://ubuntuforums.org/showpost.php?p=7061606&postcount=595 (post #595 grub2074.tar.gz ) On Tue, Apr 14, 2009 at 9:17 PM, Peter Cros wrote: > Hi, > SVN rev 2074 should be good for Xserve1,1 and 1,2 according to tests we ran > at ubuntu forums. > > > On Tue, Apr 14, 2009 at 6:23 PM, Drew Rosen wrote: > >> Hi Peter Cros, >> >> If you need anyone to run tests on the Xserve, I have a score of machines >> that we want to use on Linux... >> >> >> >> >> On Apr 9, 2009, at 7:23 AM, Peter Cros wrote: >> >> Hi, >>> It will be good to get this resolved and on SVN grub2 so people >>> (ubuntuforums) can build for Apple efi with the latest 'hacks' >>> (fakebios, loadbios etc) found necessary in testing. Particlarly >>> Xserve which requires efi boot. >>> >>> >>> On 4/7/09, Bean wrote: >>> >>>> On Tue, Apr 7, 2009 at 8:37 AM, Yoshinori K. Okuji >>>> wrote: >>>> >>>>> On Tuesday 07 April 2009 01:43:17 Bean wrote: >>>>> >>>>>> On Sat, Apr 4, 2009 at 8:53 PM, Bean wrote: >>>>>> >>>>>>> On Sat, Apr 4, 2009 at 5:30 PM, Yoshinori K. Okuji >>>>>>> >>>>>> wrote: >>>>> >>>>>> I've undone r2063, since we're still discussing how to / not to split >>>>>>>> modules. Bean, you must respect teamwork. If you are unable to >>>>>>>> follow >>>>>>>> such a fundamental rule, I will have to disable your permission. >>>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I thought the previous mail is about replacing grub_printf with >>>>>>> grub_dprint, I'm ok with that. This patch has been in mail list for >>>>>>> sometime, it is essential to get a working display in intel macs. >>>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> How about this patch ? The split is necessary as it introduces new >>>>>> command loadbios and fakebios that uses the fake_bios_data function, >>>>>> and it would be ugly to put them all inside linux.c. >>>>>> >>>>> >>>>> Do you have any strong reason to make loadbios and fakebios separate? I >>>>> think >>>>> the overhead is negligible. >>>>> >>>> >>>> Hi, >>>> >>>> loadbios and fakebios are sort of like hacks for the efi platform, I >>>> think they shouldn't be placed in the linux loader. Also, by moving >>>> the platform dependent code out, we can merge it with i386 generic >>>> loader loader/i386/linux.c. >>>> >>>> -- >>>> Bean >>>> >>>> >>>> ___ >>>> 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 >>> >> >> >> >> ___ >> Grub-devel mailing list >> Grub-devel@gnu.org >> http://lists.gnu.org/mailman/listinfo/grub-devel >> > > > > -- > Cros (pxw) > > > -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] bless command
Hi, Tested and works on Apple imac81 with Mac OSX 10.5, patch applied to r 2074 grub> hfspbless (hd0,3)/efi Last login: Sun Apr 19 14:30:23 on console im81:~ pxw$ bless --info /Volumes/hfsp finderinfo[0]: 52 => Blessed System Folder is /Volumes/hfsp/efi finderinfo[1]: 0 => No Blessed System File finderinfo[2]: 0 => Open-folder linked list empty finderinfo[3]: 0 => No OS 9 + X blessed 9 folder finderinfo[4]: 0 => Unused field unset finderinfo[5]: 0 => No OS 9 + X blessed X folder 64-bit VSDB volume id: 0x0F87F7680B9C5211 im81:~ pxw$ Now it just needs to bless the file in order to boot from grub.efi on Apple EFI hfspbless This would be VERY useful, making grub.efi boot possible on Apple Mac without needing Mac OSX or refit. hfspbless is fine for a name 2009/4/19 Vladimir Serbinenko > Hello, due to request by ams I wrote this. It's an analog of "bless" > command available under OSX rewritten using grub2 fs functions and according > to apple specification of hfs+ on-disk format. This command only update the > blessed folder on a partition it doesn't change which drive is used for > booting. The later will be a separate command. Also you can choose which > volume to boot from by holding option key. Syntax: > hfspbless > It works only on HFS+ volumes. Also due to the lack of hardware I wasn't > unable to test this "in vivo" > > > > ___ > 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: [PATCH] bless command
bless.diff version 2. success. cleared all bless on hfsplus partition in OSX. grub> hfspbless (hd0,3)/efi/test/grub523.efi Back to OSX - Last login: Sun Apr 19 22:48:43 on console im81:~ pxw$ bless --info /Volumes/hfsp finderinfo[0]: 75 => Blessed System Folder is finderinfo[1]: 7857 => Blessed System File is /Volumes/hfsp/efi/test/grub523.efi finderinfo[2]: 0 => Open-folder linked list empty finderinfo[3]: 0 => No OS 9 + X blessed 9 folder finderinfo[4]: 0 => Unused field unset finderinfo[5]: 0 => No OS 9 + X blessed X folder 64-bit VSDB volume id: 0x0F87F7680B9C5211 It boots - Restart with option key gives the Apple EFI disk icon, which boots grub523.efi Confirmed with shutdown-restart again. Redundant info - I checked the OSX bless utility, it requires both folder and file, or it will not agree to bless the file. im81:~ pxw$ sudo bless --folder /Volumes/hfsp/efi/test --file /Volumes/hfsp/efi/test/grub523.efi im81:~ pxw$ bless --info /Volumes/hfsp finderinfo[0]: 7882 => Blessed System Folder is /Volumes/hfsp/efi/test finderinfo[1]: 7885 => Blessed System File is /Volumes/hfsp/efi/test/grub523.efi Now all we need is --setBoot to make grub.efi the default boot, no Option key required. Oh, and how do we get grub.efi booted to bless itself - the only way I know at present is to use a rEFIt CD, which is bootable by Apple EFI. On Sun, Apr 19, 2009 at 8:50 PM, Vladimir Serbinenko wrote: > Hello, thank you for the testing. Two concepts together (system folder and > system file) are clearly redundant. I thought that intel macs look which > folder is blessed and load boot.efi file from this directory. Here I attach > a patch which updates finderinfo[0] when argument is a directory and > finderinfo[1] when argument is a file. Can you do a test and tell me which > concept is really used by intel macs? When doing tests don't forget to hold > option key and select your testing partition. I will do a similar test on my > ppc mac > > > On Sun, Apr 19, 2009 at 6:51 AM, Peter Cros wrote: > >> Hi, >> >> Tested and works on Apple imac81 with Mac OSX 10.5, patch applied to r >> 2074 >> >> grub> hfspbless (hd0,3)/efi >> >> Last login: Sun Apr 19 14:30:23 on console >> im81:~ pxw$ bless --info /Volumes/hfsp >> finderinfo[0]: 52 => Blessed System Folder is /Volumes/hfsp/efi >> finderinfo[1]: 0 => No Blessed System File >> finderinfo[2]: 0 => Open-folder linked list empty >> finderinfo[3]: 0 => No OS 9 + X blessed 9 folder >> finderinfo[4]: 0 => Unused field unset >> finderinfo[5]: 0 => No OS 9 + X blessed X folder >> 64-bit VSDB volume id: 0x0F87F7680B9C5211 >> im81:~ pxw$ >> >> Now it just needs to bless the file in order to boot from grub.efi on >> Apple EFI >> >> hfspbless >> >> This would be VERY useful, making grub.efi boot possible on Apple Mac >> without needing Mac OSX or refit. >> >> hfspbless is fine for a name >> >> >> 2009/4/19 Vladimir Serbinenko >> >>> Hello, due to request by ams I wrote this. It's an analog of "bless" >>> command available under OSX rewritten using grub2 fs functions and according >>> to apple specification of hfs+ on-disk format. This command only update the >>> blessed folder on a partition it doesn't change which drive is used for >>> booting. The later will be a separate command. Also you can choose which >>> volume to boot from by holding option key. Syntax: >>> hfspbless >>> It works only on HFS+ volumes. Also due to the lack of hardware I wasn't >>> unable to test this "in vivo" >>> >>> >>> >>> ___ >>> 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 >> >> > > ___ > 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: [PATCH] bless command
Thanks that is going to be very useful. Just some further comment from the little I know - On Mon, Apr 20, 2009 at 12:14 AM, Vladimir Serbinenko wrote: > >> > Now the question is how we do it. We can either keep the current syntax or > IMO it's better to have two commands: > intelmacbless and ppcmacbless both accepting file as an argument. First one > updates finderInfo[1] and the second one updates finderInfo[0] and sets > filetype of given file to tbxi and if any other file has the type tbxi in > the same directory then change it to any other value (e.g. tbxj) > The finderinfo[1] file blessing does seem the best for intel mac, but just based on my imac81 test with current EFI. >> Now all we need is --setBoot to make grub.efi the default boot, no Option >> key required. >> > In my todo. Thanks to ams I have all the needed info now > >> Oh, and how do we get grub.efi booted to bless itself - the only way I >> know at present is to use a rEFIt CD, which is bootable by Apple EFI. >> > I don't understand your question but hfspbless works in grub-emu too. > Do you mean run grub-emu as part of a linux installation to bless grub.ef? It seems to leave the problem of booting the linux installer, which is easy to do from grub.efi - if it is blessed. At present we install grub.efi manually, using only grub-mkimage to build grub.efi, without using other grub utilities, and mostly just use preloaded modules. Here is some more info for the intel mac - Further checking shows that Apple EFI will detect and boot an unblessed file named boot.efi but only if the enclosing folder is blessed. Will not boot unblessed grub.efi in the same folder. im81:~ pxw$ bless --info /Volumes/hfsp finderinfo[0]: 7891 => Blessed System Folder is /Volumes/hfsp/efi/test finderinfo[1]: 0 => No Blessed System File finderinfo[2]: 0 => Open-folder linked list empty finderinfo[3]: 0 => No OS 9 + X blessed 9 folder finderinfo[4]: 0 => Unused field unset finderinfo[5]: 7891 => OS X blessed folder is /Volumes/hfsp/efi/test 64-bit VSDB volume id: 0x0F87F7680B9C5211 im81:~ pxw$ ls /Volumes/hfsp/efi/test boot.efi grub.cfg grub523.efi grub523.icns grub64.icns im81:~ pxw$ That boots boot.efi using the Option key. For OSX boot.efi - im81:~ pxw$ bless --info / finderinfo[0]:149 => Blessed System Folder is /System/Library/CoreServices finderinfo[1]: 297081 => Blessed System File is /System/Library/CoreServices/boot.efi finderinfo[2]: 0 => Open-folder linked list empty finderinfo[3]: 0 => No OS 9 + X blessed 9 folder finderinfo[4]: 0 => Unused field unset finderinfo[5]:149 => OS X blessed folder is /System/Library/CoreServices 64-bit VSDB volume id: 0x0F8CB2A6A4C456E8 > >> -- >> Cros (pxw) >> >> >> >> ___ >> 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 > > -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] gptsync
Hi, Compiled with rev 2121, --with-platform=efi but got no gptsync module. It could be a useful tool for macs, I would like to try it. On Mon, Apr 20, 2009 at 9:17 AM, Vladimir Serbinenko wrote: > Hello, this is a common way to boot non GPT-aware OS on GPT systems. For > this protective MBR is replaced by a so-called hybrid mbr where first > partition entry is a protective entry and the rest contains legal > partitions. So here is the syntax: > gptsync DISK [PARTITIONSPEC1] [PARTITIONSPEC2] [PARTITIONSPEC3] > PARTITIONSPEC says which partitions have to be shown to legacy OS. It > always begins with the partition number. Then optionally goes one of the > following: > nothing. Autodetect partition type, not active partition > "+". Like preceding but make partition active > "-TYPE". Use TYPE type as MBR partition type > "+TYPE". Like preceding but make partition active > > > > ___ > 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: [PATCH] bless command
Hi, On Mon, Apr 20, 2009 at 6:05 AM, Vladimir Serbinenko wrote: > Hello > >> >> You can use the bootable CD of your favourite distro. I hope that > grub2.efi will become a default bootloader to install on efi system for > major linux distributions > The thought was just to avoid dependance on the apple pc-bios emulation and go toward a grub.efi installation as you suggest. (Also the apple Xserve machines do not have pc-bios emulation.) > Could you determine the priority? E.g. if you have both blessed file and >> boot.efi in blessed directory which one is loaded? >> > In both these cases the blessed grub.efi file is selected and boots. The boot.efi file here is a copy of the OSX boot.efi im81:~ pxw$ bless --info /Volumes/hfsp finderinfo[0]: 7891 => Blessed System Folder is finderinfo[1]: 8123 => Blessed System File is /Volumes/hfsp/efi/test/grub523.efi im81:~ pxw$ bless --info /Volumes/hfsp finderinfo[0]: 8120 => Blessed System Folder is /Volumes/hfsp/efi/test finderinfo[1]: 8123 => Blessed System File is /Volumes/hfsp/efi/test/grub523.efi im81:~ pxw$ ls /Volumes/hfsp/efi/test/*.efi /Volumes/hfsp/efi/test/boot.efi /Volumes/hfsp/efi/test/grub523.efi -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] bless command
My reply was delayed by network going down. On Mon, Apr 20, 2009 at 9:52 PM, Vladimir Serbinenko wrote: > > >> > The bootable cd can have both eltorito (bios) and grub2.efi > I like the grub.efi CD. > But what happens if you do something like: > blessed folder -> /test1 contains boot.efi > blessed file -> /test2/grub2.efi > grub.efi wins. We have this - (not exactly as above ) /Volumes/hfsp/boot.efi /Volumes/hfsp/efi/test/grub523.efi im81:~ pxw$ bless --info /Volumes/hfsp finderinfo[0]: 2 => Blessed System Folder is /Volumes/hfsp/ finderinfo[1]: 8256 => Blessed System File is /Volumes/hfsp/efi/test/grub523.efi finderinfo[2]: 0 => Open-folder linked list empty finderinfo[3]: 0 => No OS 9 + X blessed 9 folder finderinfo[4]: 0 => Unused field unset finderinfo[5]: 2 => OS X blessed folder is /Volumes/hfsp/ 64-bit VSDB volume id: 0x0F87F7680B9C5211 Apple Option restart shows the EFI boot icon, this boots grub523.efi, Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] gptsync
Hi, I have been playing with grub gptsync, on apple intel mac with GUID partitioned 8 GB usb stick, 8 partitions. #1 is the standard fat32 EFI system part for macs. I am comparing with the gptsync utility from linux, or rEFIt gptsync, currently used for macs booting pc-bios bootloader. It is working to allow selection of GPT partions for MBR 2, 3, 4 but some of the numbers look wrong. I have not tried setting flags. grub gptsync is not handling MBR partition table 1 the same way as current linux or refit gptsync, which puts GPT partition 1 (EFI system FAT32) in MBR part1. GPT Partions are (512 byte sectors) Current GPT partition table: # Start LBA End LBA Type 1 40 409639 EFI System (FAT) 2 409640 2395367 Mac OS X HFS+ 32395368 4573255 Mac OS X HFS+ 44835400 7141399 Mac OS X HFS+ 57403544 9965767 Mac OS X HFS+ 6 10227912 13046359 Mac OS X HFS+ 7 13308504 15642623 Mac OS X HFS+ 8 15904768 15949783 Mac OS X HFS+ There seems to be agreement about start and end on MBR table partitions 2 3 4, using grub> gptsync (hd0) 2 3 4. Other bytes differ (type, flags). This is after grub> gptsync (hd0) 2 3 4 (MBR part1 was initially set by linux gptsync) p...@im81:~$ sudo hexdump -Cn80 -s432 /dev/sdb [sudo] password for pxw: 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 01c0 02 00 ee 7f 0e 19 01 00 00 00 27 40 06 00 00 7f |..'@| 01d0 0f 19 83 1a 2d 95 28 40 06 00 c0 4c 1e 00 00 1a |-.(@...L| 01e0 2e 95 83 ab 57 1c e8 8c 24 00 60 3b 21 00 00 fc |W...$.`;!...| 01f0 59 2c 83 87 63 bc 48 c8 49 00 d0 2f 23 00 55 aa |Y,..c.H.I../#.U.| 0200 Then as seen in linux gptsync, Current MBR partition table: # AStart LBA End LBA Type 1 1 409639 ee EFI Protective 2 409640 2395367 83 Linux 32395368 4573255 83 Linux 44835400 7141399 83 Linux Status: MBR table must be updated. Proposed new MBR partition table: # AStart LBA End LBA Type 1 1 409639 ee EFI Protective 2 * 409640 2395367 af Mac OS X HFS+ 32395368 4573255 af Mac OS X HFS+ 44835400 7141399 af Mac OS X HFS+ May I update the MBR as printed above? [y/N] y Yes p...@im81:~$ sudo hexdump -Cn80 -s432 /dev/sdb 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fe || 01c0 ff ff ee fe ff ff 01 00 00 00 27 40 06 00 80 fe |..'@| 01d0 ff ff af fe ff ff 28 40 06 00 c0 4c 1e 00 00 fe |..(@...L| 01e0 ff ff af fe ff ff e8 8c 24 00 60 3b 21 00 00 fe |$.`;!...| 01f0 ff ff af fe ff ff 48 c8 49 00 d0 2f 23 00 55 aa |..H.I../#.U.| 0200 -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] gptsync
There appears to be a small bug there. For example - gptsync (hd0) 4 2 3 will write data for GPT partition 4 2 3 to MBR partition table 2 3 4 but also GPT partition 1 to MBR partition 1 (which is actually what happens now for intel mac.) And similarly for other selections will write the next lower gpt partition number to MBR partition 1 slot. I don't think it is compatible with current MBR/GPT hybrid partitioning on intel macs for grub-pc booting. On Wed, Apr 22, 2009 at 1:10 AM, Vladimir Serbinenko wrote: > > > On Tue, Apr 21, 2009 at 1:29 PM, Peter Cros wrote: > >> Hi, >> >> I have been playing with grub gptsync, on apple intel mac with GUID >> partitioned 8 GB usb stick, 8 partitions. #1 is the standard fat32 EFI >> system part for macs. >> >> I am comparing with the gptsync utility from linux, or rEFIt gptsync, >> currently used for macs booting pc-bios bootloader. >> >> It is working to allow selection of GPT partions for MBR 2, 3, 4 but some >> of the numbers look wrong. I have not tried setting flags. >> >> grub gptsync is not handling MBR partition table 1 the same way as current >> linux or refit gptsync, which puts GPT partition 1 (EFI system FAT32) in MBR >> part1. >> > I don't understand what you mean. I will not do any special treatment for > EFI system partition. As far as I'm concerned it's just a partition. I don't > think it's a problem since user can ask which partitions to put in MBR > >> >> >> GPT Partions are >> (512 byte sectors) >> Current GPT partition table: >> # Start LBA End LBA Type >> 1 40 409639 EFI System (FAT) >> 2 409640 2395367 Mac OS X HFS+ >> 32395368 4573255 Mac OS X HFS+ >> 44835400 7141399 Mac OS X HFS+ >> 57403544 9965767 Mac OS X HFS+ >> 6 10227912 13046359 Mac OS X HFS+ >> 7 13308504 15642623 Mac OS X HFS+ >> 8 15904768 15949783 Mac OS X HFS+ >> >> There seems to be agreement about start and end on MBR table partitions 2 >> 3 4, using grub> gptsync (hd0) 2 3 4. >> Other bytes differ (type, flags). >> >> This is after grub> gptsync (hd0) 2 3 4 >> (MBR part1 was initially set by linux gptsync) >> >> p...@im81:~$ sudo hexdump -Cn80 -s432 /dev/sdb >> [sudo] password for pxw: >> 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> || >> 01c0 02 00 ee 7f 0e 19 01 00 00 00 27 40 06 00 00 7f >> |..'@| >> 01d0 0f 19 83 1a 2d 95 28 40 06 00 c0 4c 1e 00 00 1a >> |-.(@...L| >> 01e0 2e 95 83 ab 57 1c e8 8c 24 00 60 3b 21 00 00 fc >> |W...$.`;!...| >> 01f0 59 2c 83 87 63 bc 48 c8 49 00 d0 2f 23 00 55 aa >> |Y,..c.H.I../#.U.| >> 0200 >> >> Then as seen in linux gptsync, >> >> Current MBR partition table: >> # AStart LBA End LBA Type >> 1 1 409639 ee EFI Protective >> 2 409640 2395367 83 Linux >> 32395368 4573255 83 Linux >> 44835400 7141399 83 Linux >> >> Status: MBR table must be updated. >> >> Proposed new MBR partition table: >> # AStart LBA End LBA Type >> 1 1 409639 ee EFI Protective >> 2 * 409640 2395367 af Mac OS X HFS+ >> 32395368 4573255 af Mac OS X HFS+ >> 44835400 7141399 af Mac OS X HFS+ >> May I update the MBR as printed above? [y/N] y >> Yes >> > Here there are 2 differences. First partition type for hfs+ isn't > autodetected, I will fix this, just I thought it ws unnecessary AFAIK every > OS which understands HFS+ understands GPT. The second thing is that none of > partiion is active. Here you have just to tell which partition is active. > You can have the same behavior as OSX gptsync with command > gptsync hd0 2+0xaf 3-0xaf 4-0xaf > Once I add hfs+ autodetect it will be enough to do > gptsync hd0 2+ 3 4 > >> >> p...@im81:~$ sudo hexdump -Cn80 -s432 /dev/sdb >> 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fe >> || >> 01c0 ff ff ee fe ff ff 01 00 00 00 27 40 06 00 80 fe >> |..'@| >> 01d0 ff ff af fe ff ff 28 40 06 00 c0 4c 1e 00 00 fe >> |..(@...L| >> 01e0 ff ff af fe ff ff e8 8c 24 00 60 3b 21 00 00 fe >> |$.`;!...| >> 01f0 ff ff af fe ff ff 48 c8 49 00 d0 2f 23 00 55 aa >> |..H.I../#.U.| >> 0200 >> >> >> >> -- >> Cros (pxw) >> >> >> >> ___ >> 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 > > -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] gptsync
On Wed, Apr 22, 2009 at 8:03 AM, Vladimir Serbinenko wrote: > About compatibiliy: hybrid MBR is against specifications - it's a trick to > boot legacy OS. So the only compatibility you can speak about is the ability > to boot a legacy OS of your choice. > >> That is exactly what I was referring to. The ability to control the ordering of partitions was attractive, not a problem. I will leave it there thanks. -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-dumpbios
On Tue, May 5, 2009 at 3:45 PM, Bean wrote: > Hi, > > I've documented the usage of grub-dumpbios in wiki page: > > http://grub.enbug.org/TestingOnMacbook > > The commands can be placed there as well. I personally doesn't mind, > but perhaps it would be easier for casual user to use a command > instead of typing the dd's directly. > Hi, It would be useful to have the commands engraved in the wiki, then it won't matter what happens to grub-dumpbios, although it was handy to have it. Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-dumpbios
On Tue, May 5, 2009 at 10:25 PM, Vladimir 'phcoder' Serbinenko < phco...@gmail.com> wrote: > > > Forgot the most important question: does it help in any way to generate a > suitable dump within grub itself? > For the user - yes, it avoids the need to use a pc-bios boot to get the dump. Or if it improves efi loadbios support for some graphics 3d agp drivers, at present this is very limited for apple efi. (works for me with ATI fglrx driver on x86 kernel, but not for nvidia or x86_64). Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Make grub2 compile with Apple's gcc
Hi, patches were applied with grub2 rev 2202, compiles and builds grub.efi in Mac OSX 10.5.6 , i686-apple-darwin9-gcc-4.0.1, with no errors, but fails to run grub.efi. ./configure --with-platform=efi --target=x86_64 ./grub-mkimage -d . -o grubosx.efi appleldr boot cat cmp chain configfile crc date echo ext2 fixvideo fat fs_uuid gpt gptsync halt help hexdump hfs hfsplus iso9660 linux loopback loadbios lspci ls minicmd memrw ntfs pc pci reboot reiserfs read scsi sleep search sh video videotest xfs rEFIt then gives - Starting grubosx.efi and hangs there (i.e. before the Welcome to GRUB). Attempt to compile macho2img.c gave error, but is this needed for x86_64? On Mon, May 11, 2009 at 2:46 AM, Vladimir 'phcoder' Serbinenko < phco...@gmail.com> wrote: > Hello. With this patch you can compile grub2 using Apple's gcc. Only > partially tested. You need objconv available from > http://www.agner.org/optimize/ licensed under GPL and additionally patched > with attached patch > Then you need to patch grub2 with attached patch. If you compile for > i386-pcbefore you begin you need to compile execute: > gcc -o macho2img util/macho2img.c -Iinclude > Then just compile grub2 normally. I will look how to automatise the > compilation of macho2img > -- > Regards > Vladimir 'phcoder' Serbinenko > > ___ > 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: [PATCH] Make grub2 compile with Apple's gcc
All good now, with the addition of grub-mkimage.c prefix workaround and apple2.diff. (grub2 rev2202) (x86_64 grub.efi booting ubuntu904 2.6.28-amd64 on MBP4,1). On Tue, May 12, 2009 at 11:54 AM, Vladimir 'phcoder' Serbinenko < phco...@gmail.com> wrote: > On Mon, May 11, 2009 at 8:04 PM, step21 wrote: > > It compiles for me, but even with outcommented line in grub-mkimage.c > > it does not start. > It's a bug in objconv with 64-bit images. Add this patch workaround > (prefix workaround still applies). Also this patch-on-patch contains > another improvement for 64-bit apple compiler > > > > On Mon, May 11, 2009 at 6:45 PM, Vladimir 'phcoder' Serbinenko > > wrote: > >> On Mon, May 11, 2009 at 6:30 PM, Vladimir 'phcoder' Serbinenko > >> wrote: > >>> On Mon, May 11, 2009 at 12:48 PM, Peter Cros > wrote: > >>>> > >>>> Hi, > >>>> patches were applied with grub2 rev 2202, compiles and builds grub.efi > in Mac OSX 10.5.6 , i686-apple-darwin9-gcc-4.0.1, with no errors, but fails > to run grub.efi. > >>>> ./configure --with-platform=efi --target=x86_64 > >>>> ./grub-mkimage -d . -o grubosx.efi appleldr boot cat cmp chain > configfile crc date echo ext2 fixvideo fat fs_uuid gpt gptsync halt help > hexdump hfs hfsplus iso9660 linux loopback loadbios lspci ls minicmd memrw > ntfs pc pci reboot reiserfs read scsi sleep search sh video videotest xfs > >>>> rEFIt then gives - > >>>> Starting grubosx.efi > >>>> and hangs there (i.e. before the Welcome to GRUB). > >>> > >> Also it looks like the problems are limited to kernel.mod. If you take > >> this file from linux build rest should be fine > >>> It's a bug in grub-mkimage - it inappropriately assumes that text is a > >>> first segment. I'll fix it. Temporarily you can just comment out the > >>> following line: > >>> util/i386/efi/grub-mkimage.c: line 104: strcpy (kernel_image + sizeof > >>> (Elf_Ehdr) + GRUB_KERNEL_MACHINE_PREFIX, prefix); > >>>> > >>>> Attempt to compile macho2img.c gave error, but is this needed for > x86_64? > >>>> > >>>> On Mon, May 11, 2009 at 2:46 AM, Vladimir 'phcoder' Serbinenko < > phco...@gmail.com> wrote: > >>>>> > >>>>> Hello. With this patch you can compile grub2 using Apple's gcc. Only > partially tested. You need objconv available from > http://www.agner.org/optimize/ licensed under GPL and additionally patched > with attached patch > >>>>> Then you need to patch grub2 with attached patch. If you compile for > i386-pcbefore you begin you need to compile execute: > >>>>> gcc -o macho2img util/macho2img.c -Iinclude > >>>>> Then just compile grub2 normally. I will look how to automatise the > compilation of macho2img > >>>>> -- > >>>>> Regards > >>>>> Vladimir 'phcoder' Serbinenko > >>>>> > >>>>> ___ > >>>>> 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 > >>>> > >>> > >>> > >>> > >>> -- > >>> Regards > >>> Vladimir 'phcoder' Serbinenko > >>> > >> > >> > >> > >> -- > >> Regards > >> Vladimir 'phcoder' Serbinenko > >> > >> > >> ___ > >> 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 > > > > > > -- > Regards > Vladimir 'phcoder' Serbinenko > > ___ > 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: [PATCH] Make grub2 compile with Apple's gcc
Also good for cross compile --target=i386, running grub32.efi on MacBook2,1. On Tue, May 12, 2009 at 1:23 PM, Peter Cros wrote: > > All good now, with the addition of grub-mkimage.c prefix workaround and > apple2.diff. (grub2 rev2202) > > (x86_64 grub.efi booting ubuntu904 2.6.28-amd64 on MBP4,1). > > > > -- 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
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: echo and hello bug
May be of interest - This is the module subset I am using with fat grub efi rev 2202 for 64/32bit efi on Imac81, MacBookPro41, MacBook21. ( ./fatglue.py grub2202fat.efi grub2202-32.efi grub2202-64.efi ) I dont use hello, but echo works. appleldr boot cat cmp chain configfile crc date echo ext2 fixvideo fat fs_uuid gpt gptsync halt help hexdump hfs hfsplus iso9660 linux loopback loadbios lspci ls minicmd memrw ntfs pc pci reboot reiserfs read scsi sleep search sh video videotest xfs. On Mon, Jun 8, 2009 at 11:39 PM, James Jarvis wrote: > Vladimir 'phcoder' Serbinenko wrote: > >> On Mon, Jun 8, 2009 at 1:34 PM, James Jarvis >> wrote: >> >> >>> I have submitted a bug in to the bugzilla at >>> >>> https://savannah.gnu.org/bugs/?26744 >>> >>> in which hello just hangs. >>> >>> I have tried a few tests around this to see if I can get any output via >>> hello from the command line (from menu pressing C) but I cannot. The >>> problem >>> also occurs if I use echo. Any suggestions on how I might try to fix this >>> (I >>> am happy to test it)? >>> >>> The fact that both hello and echo seem to exhibit the same problem >>> suggests >>> it is not the input as the former is set as a string in the code. >>> >>> >> What is your build environment? >> >> > I build on Ubuntu 9.04 SMP x86_64 on the iMac 9,1 > > I tend to use a fat binary using - the dev is towards a grub image to work > on both 32 and 64 bit macs however I have tested just as 64 bit and it has > the same error. As the bug report says I compile and build for efi platform. > In OSX the efi.tar.gz is unpacked to MacOSX root (hd0,1)/ and bless the > (hd0,1)/efi/grub/grub.efi there. > > Menus work. Appleloader works. > > I have attached the script I use to build it. > > James > > > > 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 >>> >>> >>> >> >> >> >> >> > > > -- > 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: [PATCH] bless command
Hi again, Could the hfspbless patch be updated and hopefully committted to provide the hfspbless module as standard in grub2. It is valuable to enable auto-booting grub.efi installation on Apple Intel Mac efi and also where Mac OSX/refit is not installed. Potentially for automated grub.efi installation on Apple. The old patch has not caught up with subsequent changes to hfsplus.c and requires editing to get it to work. On Sun, Apr 19, 2009 at 4:59 AM, Vladimir Serbinenko wrote: > Hello, due to request by ams I wrote this. It's an analog of "bless" > command available under OSX rewritten using grub2 fs functions and according > to apple specification of hfs+ on-disk format. This command only update the > blessed folder on a partition it doesn't change which drive is used for > booting. The later will be a separate command. Also you can choose which > volume to boot from by holding option key. Syntax: > hfspbless > It works only on HFS+ volumes. Also due to the lack of hardware I wasn't > unable to test this "in vivo" > > > > ___ > 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: Apple Xserve running Fedora
Hi, We have posts from people with Xserve1,1 and Xserve3,1 running Fedora-11 at Ubuntuforums, Apple sub froum, grub-efi thread. More details there. http://ubuntuforums.org/showthread.php?t=995704 post#909 Xserve3,1 post#879 Xserve1,1 On Tue, Aug 4, 2009 at 4:04 AM, drew rosen wrote: > Hi Guys. > > We're under a deadline to get our Xserve's running fedora. Looking forward > to signing into the IRC to get some help pushing thru the EFI issues. > > Does anyone have any fresh tips / newest file we should use? > > Thanks. > > -- > > > Drew Rosen > drew...@mac.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: booting iso image having syslinux
Some comments about live iso booting and grub2 loopback - After grub boots the live iso kernel and initrd, they need to loop mount the iso again to access the live files. Otherwise the initrd would need rebuild, or some way found to pass the loop mount from grub. I have been trying some available live iso's (there are others out there). I am using grub.efi, not using syslinux.. These live isos do loop mount the iso, and run - ununtu, grml, slax. These don't - fedora, debian, gparted. In all cases, grub loopback mounting of the iso and booting the kernel and initrd works. On Fri, Aug 7, 2009 at 9:57 PM, J.Bakshi wrote: > > > > Are you using vga= ? I fixed a bug recently (in SVN) that may cause this > > behaviour. > > > > Then I have to reinstall grub from my sqeeeze box to the usb-stick > again to see the effect. > > > ___ > 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: booting iso image having syslinux
It could be easier to use the partedmagic live iso, pmagic-4.3.iso, (kernel 2.6.30.1-pmagic), which does loop mount iso with 64 bit grub.efi loopback on Apple mac (It has gparted). On Sat, Aug 8, 2009 at 9:50 PM, J. Bakshi wrote: > On Sat, 8 Aug 2009 12:34:12 +0200 > "Vladimir 'phcoder' Serbinenko" wrote: > > > > I don't know if it is a coincident but your timing to share these > > > info is directly connected with my problem. I am presently trying > > > to collect some live iso in my usb stick and like to call those by > > > grub2. gparted is one of them. I have in mind to use gparted iso > > > but you have already mentioned that it can't be. Is there any other > > > work around within grub to cope with these type of iso ? > > It's not a question about grub but about initrd being or not being > > able to loopmount. Ask gparted live guys to add this feature to their > > scripts > > > > > I'll do it. > > > ___ > 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: Creating an (Apple) EFI bootable media
OSX bless works for me with grub.efi in any hfsplus partition using the form bless --folder /xyz --file /xyz/grub/grub.efi (if the file paths are correct - I use GUI and drag the file icon onto a terminal commandline) However it is not always necessary to bless. On Apple Mac, the UEFI spec will boot *.efi without needing to be blessed, and without refit, if it fits the naming convention in the UEFI spec. So a simple bootable package can be built. http://www.uefi.org/specs/ - EFI System Partition Subdirectory Registry UEFI Specification Version 2.3 3.4.1.1 Removable Media Boot Behavior - Table 9. UEFI Image Types If grub.efi is renamed to bootx64.efi or bootia32.efi and placed in fat32 or hfsplus tree /efi/boot, it will then be shown on the restart with Optiion key. However to get an automatic default boot, probably requires the bless form with the --setBoot option. For Apple Mac with 64 bit EFI - p...@im:~/test$ tree efi efi `-- boot |-- bootx64.efi |-- bootx64.icns `-- grub.cfg -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Macbook, Efi, Display mode
There is a grub.efi binary with the double buffering fix and menutest from Bean here on Ubuntuforms.org apple mac subforum thread grub2 EFI boot loader internal/external booting post #1054 http://ubuntuforums.org/showpost.php?p=8034856&postcount=1054 On Sun, Oct 4, 2009 at 7:55 AM, Stefan Bienert wrote: > Hi again, > > sorry, my git-foo is not that good, can you help me getting into testing > the demo from you menu branch? > > I already cloned a copy of your repo, but I do not know how to get into > a particular branch, there. > > greetings, > > Stefan > > > Hi, > > > > Oh, that could be the double buffer problem, perhaps you can try my > > latest graphic menu test demo in the menu branch. > > > > > > ___ > 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: [GITGRUB] New menu interface (implementation)
Demo auto scrolling runs OK on apple efi but some comments - Problem with different scaling between Text and Graphic mode on 1920x1200, text loses the bottom 7th widget selection possibility. I seem to expect an initial visible focussed panel indication, instead of having to hit N to see it. Perhaps that is irrelevant at this stage. Posted pictures on ubuntuforms to show Text versus Gfx. On Sun, Oct 4, 2009 at 3:27 PM, Bean wrote: > On Sun, Oct 4, 2009 at 6:34 AM, Michal Suchanek > wrote: > > 2009/10/3 Bean : > >> Hi, > >> > >> Update: > >> > >> Add auto scrolling support, view port would be adjusted automatically > >> to show the current node. In the demo, there are five horizontal > >> widgets, total length exceed that of the screen, using 'N' and 'P' to > >> navigating between anchors, and you can see the hidden widget would > >> scroll into view automatically, ESC to exit the demo. > >> > > > > Hello, > > > > Do you have an update of the sample configuration for menu test? > > > > The old sample reports "class not found". > > Hi, > > It's at: > > http://grub4dos.sourceforge.net/menu.zip > > Download it again and replace the files. > > -- > Bean > > gitgrub home: http://github.com/grub/grub/ > my fork page: http://github.com/bean123/grub/ > > > ___ > 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: Macbook, Efi, Display mode
$ git pull origin menu On Mon, Oct 5, 2009 at 7:43 AM, Stefan Bienert wrote: > >>> Hi, > >>> > >>> What's your video card, intel or nvidia ? > >>> > >> Nvidia. > > > > Hi, > > > > I found a small bug that could be the cause, please try the latest > > code from menu branch. I also upload the binary file to ubuntu forum > > in case you don't want to compile it yourself. > > > > OK, I tried that. (BTW, my clone of your repo only has the master > branch, what could I do about this?) > > Now I'm back with my old menu, no fancy graphics and no terminal. > At least the menu is not disturbed any longer. > > greetings, > > Stefan > > > ___ > 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: [GITGRUB] New menu interface (implementation)
I find that the 2 terminal configuration with hotkey switch can be very useful alternative in some situations (debugging ...) , particularly on 1920x1200 screen. Single screen popup can be default for normal use. On Wed, Oct 21, 2009 at 6:31 AM, Michal Suchanek wrote: > 2009/10/20 Bean : > > > menu_prev_anchor, you can assign these to other keys. The demo adds > > the two terminal example. Inside terminal, direction key and TAB are > > all used, so you need to assign another hotkey to switch between the > > two window. The demo uses f6: > > > > f6 = menu_next_anchor > > This is an interesting addition but I'm not sure where this would be used. > > Normally one terminal is enough so you can just open it fullscreen and > close it when you want to do something else. > > Thanks > > Michal > > > ___ > 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: [GITGRUB] New menu interface (implementation)
I don't know what is the testing status for pc machines, but I have grub-install problem for platform pc on Apple with the current menu source. commit eb03e2575b2c0b1b4fd83f33a741f6fef3b93339 Author: Bean Date: Wed Oct 21 01:11:27 2009 +0800 Compiling for grub-pc test of menu on Apple, --wth-platform=pc, I get this stopper in grub-install (after successful make && make install). OS is ubuntu904 on imac81. p...@im:~/src/grub/buildpc$ sudo ./grub-install --no-floppy --force /dev/sda ./grub-install: 312: realpath: not found ( I got the same back from start of the menu tests with git branch master, the change to realpath problem, then I went to efi tests, no problems). I had no problem --with-platform=pc from the new Bazaar mirror bzr branch http://bzr.savannah.gnu.org/r/grub/ which compiles installs and boots grub-pc with no errors . p...@im:~/src/bzr/trunk$ bzr log -l 1 revno: 1768 committer: fzielcke timestamp: Wed 2009-10-21 12:22:05 + message: 2009-10-21 Felix Zielcke --- -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [GITGRUB] New menu interface (implementation)
I can use grub-mkrescue to create an El Torito image and burn CD which boots and can run menu. Is that what you mean, or is there a way to boot direct from iso? Thanks On Fri, Oct 23, 2009 at 6:31 PM, Bean wrote: > On Fri, Oct 23, 2009 at 1:59 PM, Peter Cros wrote: > > I don't know what is the testing status for pc machines, but I have > > grub-install problem for platform pc on Apple with the current menu > source. > > > > commit eb03e2575b2c0b1b4fd83f33a741f6fef3b93339 > > Author: Bean > > Date: Wed Oct 21 01:11:27 2009 +0800 > > > > Compiling for grub-pc test of menu on Apple, --wth-platform=pc, I get > this > > stopper in grub-install (after successful make && make install). OS is > > ubuntu904 on imac81. > > > > > > p...@im:~/src/grub/buildpc$ sudo ./grub-install --no-floppy --force > /dev/sda > > ./grub-install: 312: realpath: not found > > > > > > ( I got the same back from start of the menu tests with git branch > master, > > the change to realpath problem, then I went to efi tests, no problems). > > > > I had no problem --with-platform=pc from the new Bazaar mirror > > bzr branch http://bzr.savannah.gnu.org/r/grub/ > > which compiles installs and boots grub-pc with no errors . > > Hi, > > My menu patch haven't synced with latest svn yet, perhaps it's some > bug fixed after my last sync. Anyway, I always create iso image when > testing pc mode, so it's possible that there is issue in grub-install > and I don't even noticed. > > -- > Bean > > gitgrub home: http://github.com/grub/grub/ > my fork page: http://github.com/bean123/grub/ > > > ___ > 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: [GITGRUB] New menu interface (implementation)
On Sat, Oct 24, 2009 at 7:04 PM, Peter Cros wrote: > I can use grub-mkrescue to create an El Torito image and burn CD which > boots and can run menu. Is that what you mean, or is there a way to boot > direct from iso? > > Thanks > > Nevermind, multiboot /grub.img works, with some bugs in gfx for bios boot on apple. (font missing no text on gfx, textmode is ok). -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Any tutorial to configure grub menu interface ?
That is a very useful doc, a good read. Thanks. On Tue, Nov 3, 2009 at 4:15 AM, Bean > > > Hi, > > I just write a document on configuration of the new menu system: > > https://help.ubuntu.com/community/Burg > > -- > Bean > > My repository: https://launchpad.net/burg > > > ___ > 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
