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 gra...@visi.com wrote: On 2009-03-12, Peter Cros pxwp...@gmail.com 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: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)
On Thursday 05 March 2009 05:59:52 Robert Millan wrote: We don't need a complete match of all the GRUB Legacy features in order to migrate. The things I identified as needed for migration in Debian are listed here: http://wiki.debian.org/GrubTransition I think Xen is fixed now though (someone can confirm?). For grub-reboot / savedefault almost all the pieces are there already (thanks to bean). For lock / password we need to agree on whether the proposed approach is acceptable, or otherwise what needs to be done. I have the same regression problem as Debian, personally. The password-based security feature is not quite important for me, but savedefault / fallback are critical to use GRUB in a remote environment (to upgrade / replace a kernel safely). So, I am ready for spending time to review any patch about this. Could you pinpoint where the proposed approach is? Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Migrating to GRUB 2 in Debian (Re: Interesting GSoC project ideas for 09)
Look at load_env/save_env commands and grub-editenv util Yoshinori K. Okuji wrote: On Thursday 05 March 2009 05:59:52 Robert Millan wrote: We don't need a complete match of all the GRUB Legacy features in order to migrate. The things I identified as needed for migration in Debian are listed here: http://wiki.debian.org/GrubTransition I think Xen is fixed now though (someone can confirm?). For grub-reboot / savedefault almost all the pieces are there already (thanks to bean). For lock / password we need to agree on whether the proposed approach is acceptable, or otherwise what needs to be done. I have the same regression problem as Debian, personally. The password-based security feature is not quite important for me, but savedefault / fallback are critical to use GRUB in a remote environment (to upgrade / replace a kernel safely). So, I am ready for spending time to review any patch about this. Could you pinpoint where the proposed approach is? Regards, Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Boot delay when using grub.efi on Mac Mini
On 2009-03-13, Peter Cros pxwp...@gmail.com wrote: A brief read of the mininmyth docs suggests it can also run on a fat partition on the gpt hard disk. No, the minimyth kernel doesn't support EFT/GPT partitioned disks. It also doesn't support SATA hard drives. Currently, it doesn't even know the hard-drive is there. If it did, it wouldn't know what to do with it. 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. Right, but the MiniMyth kenel can only handle msdos parition tables, and Macs will only boot from GPT partioned disks. 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. Thanks. You need to read the Mac OSX bless manual closely to compare the options, and experiment. I've read that man page dozens of times. It's pretty vague. One thing that's confusing it talks a lot about the volume -- always in the singular. I can't figure out to what volume refers such that there is never more than one in a system. 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. At this point, there aren't any grub development issues. Grub works fine. The current issues are caused by: 1) Mac firmware not being able to boot from anything other than an HFS+ partion on a GPT partioned drive. 2) MiniMyth kernel lacks support for EFI/GPT parition tables and SATA hard drives. I'm going to try rebuilding MiniMyth with GPT support so that I can GPT partition a USB flash drive in hopes of getting the Mac to boot from it. I'm also going to try adding AHCI SATA controller support to MiniMyth so that I can spin down the hard-drive. 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. That's sort of heading the wrong direction. My goal is not to have to touch the Mac hard-drive at all. So far, that's not been possible, but I'm getting closer. -- Grant Edwards grante Yow! We just joined the at civil hair patrol! visi.com ___ 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
Have you tried booting from hfs+ on msdos? Grant Edwards wrote: On 2009-03-13, Peter Cros pxwp...@gmail.com wrote: A brief read of the mininmyth docs suggests it can also run on a fat partition on the gpt hard disk. No, the minimyth kernel doesn't support EFT/GPT partitioned disks. It also doesn't support SATA hard drives. Currently, it doesn't even know the hard-drive is there. If it did, it wouldn't know what to do with it. 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. Right, but the MiniMyth kenel can only handle msdos parition tables, and Macs will only boot from GPT partioned disks. 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. Thanks. You need to read the Mac OSX bless manual closely to compare the options, and experiment. I've read that man page dozens of times. It's pretty vague. One thing that's confusing it talks a lot about the volume -- always in the singular. I can't figure out to what volume refers such that there is never more than one in a system. 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. At this point, there aren't any grub development issues. Grub works fine. The current issues are caused by: 1) Mac firmware not being able to boot from anything other than an HFS+ partion on a GPT partioned drive. 2) MiniMyth kernel lacks support for EFI/GPT parition tables and SATA hard drives. I'm going to try rebuilding MiniMyth with GPT support so that I can GPT partition a USB flash drive in hopes of getting the Mac to boot from it. I'm also going to try adding AHCI SATA controller support to MiniMyth so that I can spin down the hard-drive. 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. That's sort of heading the wrong direction. My goal is not to have to touch the Mac hard-drive at all. So far, that's not been possible, but I'm getting closer. -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Boot delay when using grub.efi on Mac Mini
On 2009-03-13, phcoder phco...@gmail.com 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. -- Grant Edwards grante Yow! Vote for ME -- I'm at well-tapered, half-cocked, visi.comill-conceived and TAX-DEFERRED! ___ 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
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 phco...@gmail.com 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
Re: [PATCH] FAT, UFS and mtime
On Sun, Mar 01, 2009 at 05:25:10PM +0100, phcoder wrote: Hello all. It seems that gcc has trouble with -m32 when structure is passed as argument. So I replaced that part by a pointer. Also I made some improvements to ufs code to support solaris branch of ufs. I tested it also with freebsd and netbsd's branch and it works fine on it too. As my 3 FS patches: mtime, FAT and UFS are interdependent I submit a patch with all 3 features. If it's really necessary I can split them but it requires a lot of unnecessary work Please do. It is definitely confusing to review patches that merge unrelated things. Also, please don't include the changelog entry in your patch, since those break too easily. Just paste it at the top of your mail. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: ELF bugfixes
On Wed, Mar 11, 2009 at 10:21:41PM +0100, phcoder wrote:
Robert Millan wrote:
On Mon, Mar 02, 2009 at 01:35:06AM +0100, phcoder wrote:
+ * include/grub/elf.h: added missing attributes
This should be a bit more descriptive.
for (i = 0; i ehdr-e_phnum; i++)
if (phdr(i)-p_type == PT_LOAD phdr(i)-p_filesz != 0)
{
- if (phdr(i)-p_paddr phdr(lowest_segment)-p_paddr)
+ if (lowest_segment == -1 + || phdr(i)-p_paddr
phdr(lowest_segment)-p_paddr)
lowest_segment = i;
- if (phdr(i)-p_paddr phdr(highest_segment)-p_paddr)
+ if (highest_segment == -1
+ || phdr(i)-p_paddr phdr(highest_segment)-p_paddr)
highest_segment = i;
}
Why?
Because if first segment doesn't have the PT_LOAD attribute set then it
should be considered in this comparison
But you didn't remove the PT_LOAD check. And in the routine below that
does the actual segment load, we still check for PT_LOAD. Those should be
consistent, right?
- grub_multiboot_payload_entry_offset = ehdr-e_entry -
phdr(lowest_segment)-p_vaddr;
+ grub_multiboot_payload_entry_offset = ehdr-e_entry -
phdr(lowest_segment)-p_paddr;
Are you sure about this? IIRC e_entry is in the virtual address space. I
think we had some trouble with this (with NetBSD?), which lead to the current
use of p_vaddr in this line.
Actually now thinking I see that the problem is more deep. The section
which is loaded at the lowest address isn't necessarily the section
which contains entry point. I'll fix this part cleanly and will resubmit
the patch
No, but AFAICT the entry point is defined relative to that address, regardless
of which segment contains it.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: precision formatting in grub_printf
On Thu, Mar 12, 2009 at 02:19:44PM +0530, Deepak Vankadaru wrote: Hi I have completed the copyright assignment procedure. Just a reminder. Hi Deepak, Thanks for the reminder. Could you please include a ChangeLog entry? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bugfix: directories: not reported as such on case-insensitive fs
On Mon, Feb 09, 2009 at 05:16:52PM +0100, phcoder wrote: - - if (filetype == GRUB_FSHELP_DIR) + + if ((filetype GRUB_FSHELP_TYPE_MASK) == GRUB_FSHELP_DIR) Please don't remove those spaces, they're intentional (see http://www.gnu.org/prep/standards/html_node/Formatting.html#Formatting) + * include/grub/fshelp.h: included definition of GRUB_FSHELP_TYPE_MASK + and GRUB_FSHELP_FLAGS_MASK This should be something like: * file (macro1, macro2): Define. or similar. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] linux/gfxterm integration
On Sun, Mar 08, 2009 at 03:35:30PM +0200, Vesa Jääskeläinen wrote:
Robert Millan wrote:
Note: As the comment in grub/video.h says, struct grub_video_render_target
didn't really want to be moved. My code only needs to access it to find
the framebuffer address. Perhaps it'd be better to move this information
elsewhere? Or split it in a separate structure / getter?
Any comments on my question about struct grub_video_render_target ?
Don't like em... Let me think it a bit.
This new patch avoids the problem by accessing struct grub_video_render_target
from its current location.
When we have more than one video backend, and a clear idea on which parts are
generic and which are backend-specific, we could readjust. For now this makes
VBE happy.
Thoughts?
--
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.
2009-03-13 Robert Millan r...@aybabtu.com
* loader/i386/linux.c: Include `grub/video.h' and
`grub/i386/pc/vbe.h'..
(grub_linux_setup_video): New function. Loosely based on the EFI one.
(grub_linux32_boot): Attempt to configure video settings with
grub_linux_setup_video().
(grub_rescue_cmd_linux): Set noreturn=0 in grub_loader_set, in order
to avoid grub_console_fini() which would step out of graphical mode
unconditionally.
Index: loader/i386/linux.c
===
--- loader/i386/linux.c (revision 2030)
+++ loader/i386/linux.c (working copy)
@@ -1,6 +1,6 @@
/*
* GRUB -- GRand Unified Bootloader
- * Copyright (C) 2006,2007,2008 Free Software Foundation, Inc.
+ * Copyright (C) 2006,2007,2008,2009 Free Software Foundation, Inc.
*
* GRUB is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -30,6 +30,10 @@
#include grub/mm.h
#include grub/term.h
#include grub/cpu/linux.h
+#include grub/video.h
+/* FIXME: the definition of `struct grub_video_render_target' is
+ VBE-specific. */
+#include grub/i386/pc/vbe.h
#define GRUB_LINUX_CL_OFFSET 0x1000
#define GRUB_LINUX_CL_END_OFFSET 0x2000
@@ -215,6 +219,41 @@ grub_e820_add_region (struct grub_e820_m
}
}
+static int
+grub_linux_setup_video (struct linux_kernel_params *params)
+{
+ struct grub_video_mode_info mode_info;
+ struct grub_video_render_target *render_target;
+ int ret;
+
+ ret = grub_video_get_info (mode_info);
+ if (ret)
+return 1;
+
+ ret = grub_video_get_active_render_target (render_target);
+ if (ret)
+return 1;
+
+ params-lfb_width = mode_info.width;
+ params-lfb_height = mode_info.height;
+ params-lfb_depth = mode_info.bpp;
+ params-lfb_line_len = mode_info.pitch;
+
+ params-lfb_base = (void *) render_target-data;
+ params-lfb_size = (params-lfb_line_len * params-lfb_height + 65535) 16;
+
+ params-red_mask_size = 8;
+ params-red_field_pos = 16;
+ params-green_mask_size = 8;
+ params-green_field_pos = 8;
+ params-blue_mask_size = 8;
+ params-blue_field_pos = 0;
+ params-reserved_mask_size = 8;
+ params-reserved_field_pos = 24;
+
+ return 0;
+}
+
#ifdef __x86_64__
struct
{
@@ -231,6 +270,9 @@ grub_linux32_boot (void)
params = real_mode_mem;
+ if (! grub_linux_setup_video (params))
+params-have_vga = GRUB_VIDEO_TYPE_VLFB;
+
grub_dprintf (linux, code32_start = %x, idt_desc = %lx, gdt_desc = %lx\n,
(unsigned) params-code32_start,
(unsigned long) (idt_desc.limit),
@@ -314,7 +356,6 @@ grub_rescue_cmd_linux (int argc, char *a
grub_ssize_t len;
int i;
char *dest;
- int video_type;
grub_dl_ref (my_mod);
@@ -422,7 +463,6 @@ grub_rescue_cmd_linux (int argc, char *a
/* Detect explicitly specified memory size, if any. */
linux_mem_size = 0;
- video_type = 0;
for (i = 1; i argc; i++)
if (grub_memcmp (argv[i], mem=, 4) == 0)
{
@@ -481,7 +521,8 @@ grub_rescue_cmd_linux (int argc, char *a
if (grub_errno == GRUB_ERR_NONE)
{
- grub_loader_set (grub_linux32_boot, grub_linux_unload, 1);
+ grub_loader_set (grub_linux32_boot, grub_linux_unload,
+ 0 /* set noreturn=0 in order to avoid grub_console_fini() */);
loaded = 1;
}
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] linux/gfxterm integration
From: Robert Millan r...@aybabtu.com Date: Fri, 13 Mar 2009 20:44:47 +0100 When we have more than one video backend, and a clear idea on which parts are generic and which are backend-specific, we could readjust. For now this makes VBE happy. I intend to write an ofvideo.c driver, so we'll have that opportunity soon. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: ELF bugfixes
Robert Millan wrote:
On Wed, Mar 11, 2009 at 10:21:41PM +0100, phcoder wrote:
Robert Millan wrote:
On Mon, Mar 02, 2009 at 01:35:06AM +0100, phcoder wrote:
+ * include/grub/elf.h: added missing attributes
This should be a bit more descriptive.
for (i = 0; i ehdr-e_phnum; i++)
if (phdr(i)-p_type == PT_LOAD phdr(i)-p_filesz != 0)
{
- if (phdr(i)-p_paddr phdr(lowest_segment)-p_paddr)
+ if (lowest_segment == -1 + || phdr(i)-p_paddr
phdr(lowest_segment)-p_paddr)
lowest_segment = i;
- if (phdr(i)-p_paddr phdr(highest_segment)-p_paddr)
+ if (highest_segment == -1
+ || phdr(i)-p_paddr phdr(highest_segment)-p_paddr)
highest_segment = i;
}
Why?
Because if first segment doesn't have the PT_LOAD attribute set then it
should be considered in this comparison
But you didn't remove the PT_LOAD check. And in the routine below that
does the actual segment load, we still check for PT_LOAD. Those should be
consistent, right?
No I expressed myself badly. Original code assumed that first segment
has PT_LOAD always set (lowest_segment is 0 initally). I removed this
assumption
- grub_multiboot_payload_entry_offset = ehdr-e_entry -
phdr(lowest_segment)-p_vaddr;
+ grub_multiboot_payload_entry_offset = ehdr-e_entry -
phdr(lowest_segment)-p_paddr;
Are you sure about this? IIRC e_entry is in the virtual address space. I
think we had some trouble with this (with NetBSD?), which lead to the current
use of p_vaddr in this line.
Actually now thinking I see that the problem is more deep. The section
which is loaded at the lowest address isn't necessarily the section
which contains entry point. I'll fix this part cleanly and will resubmit
the patch
No, but AFAICT the entry point is defined relative to that address, regardless
of which segment contains it.
Actually our segment table is also our table for transforming between
virtual and physical address. I don't see why entry point would be
defined against virtual address of lowest physical segement
--
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bugfix: directories: not reported as such on case-insensitive fs
Robert Millan wrote: On Mon, Feb 09, 2009 at 05:16:52PM +0100, phcoder wrote: - if (filetype == GRUB_FSHELP_DIR) + if ((filetype GRUB_FSHELP_TYPE_MASK) == GRUB_FSHELP_DIR) Uhm actually I don't understand why you need a mask for this. filetype is an enum, which we define ourselves. What's the root of the problem? The usage of #define GRUB_FSHELP_CASE_INSENSITIVE0x100 as a flag on filetype -- Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: ELF bugfixes
From: phcoder phco...@gmail.com Date: Fri, 13 Mar 2009 21:41:42 +0100 Actually our segment table is also our table for transforming between virtual and physical address. I don't see why entry point would be defined against virtual address of lowest physical segement I would suggest simply looping over the phdrs and remembering which one the e_entry falls into. Won't that make things work in the case you're describing? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: ELF bugfixes
David Miller wrote:
From: phcoder phco...@gmail.com
Date: Fri, 13 Mar 2009 21:41:42 +0100
Actually our segment table is also our table for transforming
between virtual and physical address. I don't see why entry point
would be defined against virtual address of lowest physical segement
I would suggest simply looping over the phdrs and remembering
which one the e_entry falls into.
Won't that make things work in the case you're describing?
I thought I have attached new patch. Sorry forgot to do so
--
Regards
Vladimir 'phcoder' Serbinenko
Index: ChangeLog
===
--- ChangeLog (revision 2036)
+++ ChangeLog (working copy)
@@ -1,3 +1,11 @@
+2009-03-01 Vladimir Serbinenko phco...@gmail.com
+
+ Bugfixes in multiboot for bugs uncovered by solaris kernel
+
+ * loader/i386/multiboot_elfxx.c (grub_multiboot_load_elf): corrected
+ limit detection
+ Use vaddr of correct segment for entry_point
+
2009-03-12 Vladimir Serbinenko phco...@gmail.com
Parttool
Index: loader/i386/multiboot_elfxx.c
===
--- loader/i386/multiboot_elfxx.c (revision 2036)
+++ loader/i386/multiboot_elfxx.c (working copy)
@@ -49,7 +49,7 @@
{
Elf_Ehdr *ehdr = (Elf_Ehdr *) buffer;
char *phdr_base;
- int lowest_segment = 0, highest_segment = 0;
+ int lowest_segment = -1, highest_segment = -1;
int i;
if (ehdr-e_ident[EI_CLASS] != ELFCLASSXX)
@@ -83,11 +83,17 @@
for (i = 0; i ehdr-e_phnum; i++)
if (phdr(i)-p_type == PT_LOAD phdr(i)-p_filesz != 0)
{
- if (phdr(i)-p_paddr phdr(lowest_segment)-p_paddr)
+ if (lowest_segment == -1
+ || phdr(i)-p_paddr phdr(lowest_segment)-p_paddr)
lowest_segment = i;
- if (phdr(i)-p_paddr phdr(highest_segment)-p_paddr)
+ if (highest_segment == -1
+ || phdr(i)-p_paddr phdr(highest_segment)-p_paddr)
highest_segment = i;
}
+
+ if (lowest_segment == -1)
+return grub_error (GRUB_ERR_BAD_OS, ELF contains no loadable segments);
+
code_size = (phdr(highest_segment)-p_paddr + phdr(highest_segment)-p_memsz) - phdr(lowest_segment)-p_paddr;
grub_multiboot_payload_dest = phdr(lowest_segment)-p_paddr;
@@ -105,8 +111,8 @@
{
char *load_this_module_at = (char *) (grub_multiboot_payload_orig + (long) (phdr(i)-p_paddr - phdr(lowest_segment)-p_paddr));
- grub_dprintf (multiboot_loader, segment %d: paddr=0x%lx, memsz=0x%lx\n,
- i, (long) phdr(i)-p_paddr, (long) phdr(i)-p_memsz);
+ grub_dprintf (multiboot_loader, segment %d: paddr=0x%lx, memsz=0x%lx, vaddr=0x%lx\n,
+ i, (long) phdr(i)-p_paddr, (long) phdr(i)-p_memsz, (long) phdr(i)-p_vaddr);
if (grub_file_seek (file, (grub_off_t) phdr(i)-p_offset)
== (grub_off_t) -1)
@@ -124,7 +130,11 @@
}
}
- grub_multiboot_payload_entry_offset = ehdr-e_entry - phdr(lowest_segment)-p_vaddr;
+ for (i = 0; i ehdr-e_phnum; i++)
+if (phdr(i)-p_vaddr = ehdr-e_entry
+ phdr(i)-p_vaddr + phdr(i)-p_memsz ehdr-e_entry)
+ grub_multiboot_payload_entry_offset = (ehdr-e_entry - phdr(i)-p_vaddr)
+ + (phdr(i)-p_paddr - phdr(lowest_segment)-p_paddr);
#undef phdr
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
[Fwd: Re: ELF bugfixes]
-- Regards Vladimir 'phcoder' Serbinenko ---BeginMessage--- From: phcoder phco...@gmail.com Date: Fri, 13 Mar 2009 21:49:39 +0100 David Miller wrote: From: phcoder phco...@gmail.com Date: Fri, 13 Mar 2009 21:41:42 +0100 Actually our segment table is also our table for transforming between virtual and physical address. I don't see why entry point would be defined against virtual address of lowest physical segement I would suggest simply looping over the phdrs and remembering which one the e_entry falls into. Won't that make things work in the case you're describing? I thought I have attached new patch. Sorry forgot to do so This patch looks good to me, FWIW. ---End Message--- ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: ELF bugfixes
On Fri, Mar 13, 2009 at 09:41:42PM +0100, phcoder wrote:
Robert Millan wrote:
On Wed, Mar 11, 2009 at 10:21:41PM +0100, phcoder wrote:
Robert Millan wrote:
On Mon, Mar 02, 2009 at 01:35:06AM +0100, phcoder wrote:
+ * include/grub/elf.h: added missing attributes
This should be a bit more descriptive.
for (i = 0; i ehdr-e_phnum; i++)
if (phdr(i)-p_type == PT_LOAD phdr(i)-p_filesz != 0)
{
- if (phdr(i)-p_paddr phdr(lowest_segment)-p_paddr)
+ if (lowest_segment == -1 + || phdr(i)-p_paddr
phdr(lowest_segment)-p_paddr)
lowest_segment = i;
- if (phdr(i)-p_paddr phdr(highest_segment)-p_paddr)
+ if (highest_segment == -1
+ || phdr(i)-p_paddr phdr(highest_segment)-p_paddr)
highest_segment = i;
}
Why?
Because if first segment doesn't have the PT_LOAD attribute set then
it should be considered in this comparison
But you didn't remove the PT_LOAD check. And in the routine below that
does the actual segment load, we still check for PT_LOAD. Those should be
consistent, right?
No I expressed myself badly. Original code assumed that first segment
has PT_LOAD always set (lowest_segment is 0 initally). I removed this
assumption
Why do we care about non-PT_LOAD segments?
- grub_multiboot_payload_entry_offset = ehdr-e_entry -
phdr(lowest_segment)-p_vaddr;
+ grub_multiboot_payload_entry_offset = ehdr-e_entry -
phdr(lowest_segment)-p_paddr;
Are you sure about this? IIRC e_entry is in the virtual address space. I
think we had some trouble with this (with NetBSD?), which lead to the
current
use of p_vaddr in this line.
Actually now thinking I see that the problem is more deep. The
section which is loaded at the lowest address isn't necessarily the
section which contains entry point. I'll fix this part cleanly and
will resubmit the patch
No, but AFAICT the entry point is defined relative to that address,
regardless
of which segment contains it.
Actually our segment table is also our table for transforming between
virtual and physical address. I don't see why entry point would be
defined against virtual address of lowest physical segement
I think entry point is supposed to be defined in virtual address space. As
to why do we check for physical addresses earlier, I'm not entirely sure. I
think the idea was that we store the entry point as an offset, so that it
can be applied to physical addresses, despite the fact that we obtained it
by comparing e_entry with a virtual address.
ISTR this being an issue for NetBSD. We should be certain what we do before
changing it. In particular, the following commit seem relevant:
2008-02-05 Bean bean12...@gmail.com
* loader/i386/pc/multiboot.c (grub_multiboot_load_elf32): Get physical
address of entry.
I'd also recommend testing your changes with NetBSD's kernel.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: ELF bugfixes
Robert Millan wrote:
On Fri, Mar 13, 2009 at 09:41:42PM +0100, phcoder wrote:
Robert Millan wrote:
On Wed, Mar 11, 2009 at 10:21:41PM +0100, phcoder wrote:
Robert Millan wrote:
On Mon, Mar 02, 2009 at 01:35:06AM +0100, phcoder wrote:
+ * include/grub/elf.h: added missing attributes
This should be a bit more descriptive.
for (i = 0; i ehdr-e_phnum; i++)
if (phdr(i)-p_type == PT_LOAD phdr(i)-p_filesz != 0)
{
- if (phdr(i)-p_paddr phdr(lowest_segment)-p_paddr)
+ if (lowest_segment == -1 + || phdr(i)-p_paddr
phdr(lowest_segment)-p_paddr)
lowest_segment = i;
- if (phdr(i)-p_paddr phdr(highest_segment)-p_paddr)
+ if (highest_segment == -1
+ || phdr(i)-p_paddr phdr(highest_segment)-p_paddr)
highest_segment = i;
}
Why?
Because if first segment doesn't have the PT_LOAD attribute set then
it should be considered in this comparison
But you didn't remove the PT_LOAD check. And in the routine below that
does the actual segment load, we still check for PT_LOAD. Those should be
consistent, right?
No I expressed myself badly. Original code assumed that first segment
has PT_LOAD always set (lowest_segment is 0 initally). I removed this
assumption
Why do we care about non-PT_LOAD segments?
We don't but without this fix non-PT_LOAD segment 1 wasn't correctly ignored
- grub_multiboot_payload_entry_offset = ehdr-e_entry -
phdr(lowest_segment)-p_vaddr;
+ grub_multiboot_payload_entry_offset = ehdr-e_entry -
phdr(lowest_segment)-p_paddr;
Are you sure about this? IIRC e_entry is in the virtual address space. I
think we had some trouble with this (with NetBSD?), which lead to the current
use of p_vaddr in this line.
Actually now thinking I see that the problem is more deep. The
section which is loaded at the lowest address isn't necessarily the
section which contains entry point. I'll fix this part cleanly and
will resubmit the patch
No, but AFAICT the entry point is defined relative to that address, regardless
of which segment contains it.
Actually our segment table is also our table for transforming between
virtual and physical address. I don't see why entry point would be
defined against virtual address of lowest physical segement
I think entry point is supposed to be defined in virtual address space. As
to why do we check for physical addresses earlier, I'm not entirely sure. I
think the idea was that we store the entry point as an offset, so that it
can be applied to physical addresses, despite the fact that we obtained it
by comparing e_entry with a virtual address.
ISTR this being an issue for NetBSD. We should be certain what we do before
changing it. In particular, the following commit seem relevant:
2008-02-05 Bean bean12...@gmail.com
* loader/i386/pc/multiboot.c (grub_multiboot_load_elf32): Get physical
address of entry.
I'd also recommend testing your changes with NetBSD's kernel.
Ok will do it
--
Regards
Vladimir 'phcoder' Serbinenko
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [Patch] Move multiboot helpers out of the kernel
Rediffed 2009-03-14 Vladimir Serbinenko phco...@gmail.com Move multiboot helper out of kernel * conf/i386-pc.rmk: Add loader/i386/multiboot_helper.S to _multiboot.mod * conf/i386-coreboot.rmk: Likewise * conf/i386-ieee1275.rmk: Likewise * kern/i386/loader.S: Move multiboot helpers from here... * loader/i386/multiboot_helper.S: ...moved here * include/grub/i386/loader.h: Move declarations of multiboot helpers from here... * include/grub/i386/multiboot.h: ...moved here * loader/i386/multiboot.c: Added include of grub/cpu/multiboot.h phcoder wrote: Hello. multiboot helpers have no real reason to stay in kernel. So here is the proposition to move them out of it to _multiboot.mod. Changelog: 2009-02-11 Vladimir Serbinenko phco...@gmail.com Move multiboot helper out of kernel * conf/i386-pc.rmk: Add loader/i386/multiboot.S to _multiboot.mod * conf/i386-coreboot.rmk: Likewise * conf/i386-ieee1275.rmk: Likewise * kern/i386/loader.S: Move multiboot helpers from here... * loader/i386/multiboot.S: ...moved here * include/grub/i386/loader.h: Move declarations of multiboot helpers from here... * include/grub/i386/multiboot.h: ...moved here * loader/i386/pc/multiboot.c: Added include of grub/cpu/multiboot.h Thanks Vladimir 'phcoder' Serbinenko -- Regards Vladimir 'phcoder' Serbinenko Index: conf/i386-pc.rmk === --- conf/i386-pc.rmk (revision 2030) +++ conf/i386-pc.rmk (working copy) @@ -238,11 +238,13 @@ # For _multiboot.mod. _multiboot_mod_SOURCES = loader/i386/multiboot.c \ + loader/i386/multiboot_helper.S \ loader/i386/pc/multiboot2.c \ loader/multiboot2.c \ loader/multiboot_loader.c _multiboot_mod_CFLAGS = $(COMMON_CFLAGS) _multiboot_mod_LDFLAGS = $(COMMON_LDFLAGS) +_multiboot_mod_ASFLAGS = $(COMMON_ASFLAGS) # For multiboot.mod. multiboot_mod_SOURCES = loader/multiboot_loader_normal.c Index: conf/i386-coreboot.rmk === --- conf/i386-coreboot.rmk (revision 2030) +++ conf/i386-coreboot.rmk (working copy) @@ -151,10 +151,12 @@ # For _multiboot.mod. _multiboot_mod_SOURCES = loader/i386/multiboot.c \ loader/i386/pc/multiboot2.c \ + loader/i386/multiboot_helper.S \ loader/multiboot2.c \ loader/multiboot_loader.c _multiboot_mod_CFLAGS = $(COMMON_CFLAGS) _multiboot_mod_LDFLAGS = $(COMMON_LDFLAGS) +_multiboot_mod_ASFLAGS = $(COMMON_ASFLAGS) # For multiboot.mod. multiboot_mod_SOURCES = loader/multiboot_loader_normal.c Index: conf/i386-ieee1275.rmk === --- conf/i386-ieee1275.rmk (revision 2030) +++ conf/i386-ieee1275.rmk (working copy) @@ -126,10 +126,12 @@ # For _multiboot.mod. _multiboot_mod_SOURCES = loader/ieee1275/multiboot2.c \ + loader/i386/multiboot_helper.S \ loader/multiboot2.c \ loader/multiboot_loader.c _multiboot_mod_CFLAGS = $(COMMON_CFLAGS) _multiboot_mod_LDFLAGS = $(COMMON_LDFLAGS) +_multiboot_mod_ASFLAGS = $(COMMON_ASFLAGS) # For multiboot.mod. multiboot_mod_SOURCES = loader/multiboot_loader_normal.c Index: kern/i386/loader.S === --- kern/i386/loader.S (revision 2030) +++ kern/i386/loader.S (working copy) @@ -118,107 +118,7 @@ .word 0 .code32 - /* - * This starts the multiboot kernel. - */ - -VARIABLE(grub_multiboot_payload_size) - .long 0 -VARIABLE(grub_multiboot_payload_orig) - .long 0 -VARIABLE(grub_multiboot_payload_dest) - .long 0 -VARIABLE(grub_multiboot_payload_entry_offset) - .long 0 - -/* - * The relocators below understand the following parameters: - * ecx: Size of the block to be copied. - * esi: Where to copy from (always lowest address, even if we're relocating - * backwards). - * edi: Where to copy to (likewise). - * edx: Offset of the entry point (relative to the beginning of the block). - */ -VARIABLE(grub_multiboot_forward_relocator) - /* Add entry offset. */ - addl %edi, %edx - - /* Forward copy. */ - cld - rep - movsb - - jmp *%edx -VARIABLE(grub_multiboot_forward_relocator_end) - -VARIABLE(grub_multiboot_backward_relocator) - /* Add entry offset (before %edi is mangled). */ - addl %edi, %edx - - /* Backward movsb is implicitly off-by-one. compensate that. */ - decl %esi - decl %edi - - /* Backward copy. */ - std - addl %ecx, %esi - addl %ecx, %edi - rep - movsb - - jmp *%edx -VARIABLE(grub_multiboot_backward_relocator_end) - -FUNCTION(grub_multiboot_real_boot) - /* Push the entry address on the stack. */ - pushl %eax - /* Move the address of the multiboot information structure to ebx. */ - movl %edx,%ebx - - /* Unload all modules and stop the floppy driver. */ - call EXT_C(grub_dl_unload_all)
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 phco...@gmail.com 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 phco...@gmail.com 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 gra...@visi.com 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
