Hi,
Recently got one of these laptops, and I've been trying to make it
work a bit better in Linux. One thing that is really annoying is that
it defaults to PIIX instead of AHCI when not booting OSX (it uses
ahci just fine). So I tried to fiddle with this a bit and get it
to use ahci, and after reading the intel specs I managed to switch
it into ahci mode.
The performance is better (512b reads are 3x as fast) and more
importantly it enables the use of ALPM would cuts about 1W of my
power consumption. That's at 30 minutes of battery.
So while the below works, it doesn't work when the laptop is
coming out of suspend. I can't seem to find out why, since it's
a bit hard to debug when you are on the road. What happens is
that it comes back with a bit of a delay, and then the disks are
apparently gone. I've tried adding a resume quirk to re-AHCI the
thing, but it doesn't help.
Looking at the specs, I don't see what I am missing to make this
work for resume. I'm assuming that EFI did initialize some bits
that am missing when coming out of resume, but I don't know which
bits.
Anyone played with this before and has some clues???
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 477345d..3635260 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -1020,6 +1020,55 @@ static void quirk_disable_pxb(struct pci_dev *pdev)
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454NX, quirk_disable_pxb);
DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454NX, quirk_disable_pxb);
+/*
+ * This enables AHCI mode on Macbook Pro 6,2 and others based on Intels
+ * 5 series / 3400 series chipset.
+ *
+ * Info found here http://www.intel.com/Assets/PDF/datasheet/322169.pdf
+ */
+static void __devinit quirk_pch_ahci(struct pci_dev *pdev)
+{
+ u16 mode;
+
+ /*
+ * 0x90 is the MAP register offset
+ */
+ pci_read_config_word(pdev, 0x90, &mode);
+
+ printk("got mode %x\n", mode);
+
+ /*
+ * MAP.MV must be 0x00 to allow ahci enable
+ */
+ if (mode & 0x03)
+ return;
+
+ /*
+ * Already in AHCI mode?
+ */
+ if (mode & (1 << 6))
+ return;
+
+ /*
+ * MAP.SMS bit 6 is AHCI mode, MAP.SC bit 5 is port config
+ */
+ mode = (1 << 6) | (1 << 5);
+ pci_write_config_word(pdev, 0x90, mode);
+
+ /*
+ * Re-read device id, it has now changed
+ */
+ pci_read_config_word(pdev, PCI_DEVICE_ID, &pdev->device);
+
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x3b28, quirk_pch_ahci);
+
+static void __devinit quirk_pch_ahci_resume(struct pci_dev *pdev)
+{
+ quirk_pch_ahci(pdev);
+}
+DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL, 0x3b29, quirk_pch_ahci_resume);
+
static void __devinit quirk_amd_ide_mode(struct pci_dev *pdev)
{
/* set SBX00/Hudson-2 SATA in IDE mode to AHCI mode */
--
Jens Axboe
On Sun, Jul 18, 2010 at 10:03:44AM -0600, Jens Axboe wrote:
> So while the below works, it doesn't work when the laptop is
> coming out of suspend. I can't seem to find out why, since it's
> a bit hard to debug when you are on the road. What happens is
> that it comes back with a bit of a delay, and then the disks are
> apparently gone. I've tried adding a resume quirk to re-AHCI the
> thing, but it doesn't help.
You'll certainly need to re-quirk on resume, since there's no guarantee
that the firmware will do it for you. My suspicion is that it comes up
in PATA mode with legacy firmware in order to improve compatibility with
XP, and you'd have ahci if you booted through EFI. I don't have
something handy to test that right now, though.
> Looking at the specs, I don't see what I am missing to make this
> work for resume. I'm assuming that EFI did initialize some bits
> that am missing when coming out of resume, but I don't know which
> bits.
There's no guarantee that the AHCI BAR is programmed by the firmware (it
seems to be on the Macs, but won't be on most hardware). Is it getting
reprogrammed on resume?
--
Matthew Garrett | [email protected]
On 07/18/2010 12:42 PM, Matthew Garrett wrote:
> On Sun, Jul 18, 2010 at 10:03:44AM -0600, Jens Axboe wrote:
>
>> So while the below works, it doesn't work when the laptop is
>> coming out of suspend. I can't seem to find out why, since it's
>> a bit hard to debug when you are on the road. What happens is
>> that it comes back with a bit of a delay, and then the disks are
>> apparently gone. I've tried adding a resume quirk to re-AHCI the
>> thing, but it doesn't help.
>
> You'll certainly need to re-quirk on resume, since there's no guarantee
> that the firmware will do it for you. My suspicion is that it comes up
> in PATA mode with legacy firmware in order to improve compatibility with
> XP, and you'd have ahci if you booted through EFI. I don't have
> something handy to test that right now, though.
See this is where I'm getting confused, since I'm not entirely sure what
the boot process is. If I boot a DVD directly, then it's in piix mode.
Booting through refit -> Linux, it's in piix mode. So my logic was that
it is probably getting switched into ahci mode by the OSX boot loader or
perhaps the driver does it there.
The resume re-quirk makes no difference, so it's likely that it needs a
bit more love when it's coming out of that state.
>> Looking at the specs, I don't see what I am missing to make this
>> work for resume. I'm assuming that EFI did initialize some bits
>> that am missing when coming out of resume, but I don't know which
>> bits.
>
> There's no guarantee that the AHCI BAR is programmed by the firmware (it
> seems to be on the Macs, but won't be on most hardware). Is it getting
> reprogrammed on resume?
The BARs are fine with just the patch I sent:
Region 0: I/O ports at 3128 [size=8]
Region 1: I/O ports at 313c [size=4]
Region 2: I/O ports at 0170 [size=8]
Region 3: I/O ports at 0374 [size=1]
Region 4: I/O ports at 3020 [size=32]
Region 5: Memory at a2800000 (32-bit, non-prefetchable) [size=2K]
Since everything is screwed on resume and all file systems are gone,
there's no easy way for me to printk() and verify anything on resume. So
unless anyone has any stellar ideas on what to try, I guess it'll have
to wait until I can log some output somehow.
--
Jens Axboe
On Sun, Jul 18, 2010 at 14:34:46 -0600, Jens Axboe wrote:
[...]
> See this is where I'm getting confused, since I'm not entirely sure what
> the boot process is. If I boot a DVD directly, then it's in piix mode.
> Booting through refit -> Linux, it's in piix mode. So my logic was that
> it is probably getting switched into ahci mode by the OSX boot loader or
> perhaps the driver does it there.
If this helps: I switched from grub-pc to grub-efi on my oldish Mac
mini Core 2 Duo (i945 chipset) and the hard disk used AHCI after this.
Suspend also works fine. So I would guess that the AHCI/PIIX difference
is caused by booting with EFI/legacy DOS bootblock, and the latter is
just done for Windows compatibility.
Regards,
Tino
On 07/18/2010 02:42 PM, Matthew Garrett wrote:
> On Sun, Jul 18, 2010 at 10:03:44AM -0600, Jens Axboe wrote:
>> Looking at the specs, I don't see what I am missing to make this
>> work for resume. I'm assuming that EFI did initialize some bits
>> that am missing when coming out of resume, but I don't know which
>> bits.
>
> There's no guarantee that the AHCI BAR is programmed by the firmware (it
> seems to be on the Macs, but won't be on most hardware). Is it getting
> reprogrammed on resume?
That's definitely the key question.
I would have quirked AHCI/piix hardware into AHCI mode long ago, if
firmwares defaulting to piix mode would actually program the PCI BAR
correctly.
Or, if the firmware had some way to safely allocate a bus memory range,
which we could ourselves program into the PCI BAR. Some non-PC
platforms can do that.
Jeff
On 07/18/2010 04:44 PM, Jeff Garzik wrote:
> On 07/18/2010 02:42 PM, Matthew Garrett wrote:
>> On Sun, Jul 18, 2010 at 10:03:44AM -0600, Jens Axboe wrote:
>>> Looking at the specs, I don't see what I am missing to make this
>>> work for resume. I'm assuming that EFI did initialize some bits
>>> that am missing when coming out of resume, but I don't know which
>>> bits.
>>
>> There's no guarantee that the AHCI BAR is programmed by the firmware (it
>> seems to be on the Macs, but won't be on most hardware). Is it getting
>> reprogrammed on resume?
>
> That's definitely the key question.
>
> I would have quirked AHCI/piix hardware into AHCI mode long ago, if
> firmwares defaulting to piix mode would actually program the PCI BAR
> correctly.
>
> Or, if the firmware had some way to safely allocate a bus memory range,
> which we could ourselves program into the PCI BAR. Some non-PC
> platforms can do that.
So I've dug a bit further, and I discovered that the AHCI BAR is indeed
not working on resume. I googled and found an older patch from Matthew
that hacks it in, but it still failed on resume. But a bit differently,
it seemed that now only interrupt delivery was problematic. I disabled
msi for this controller, and bingo it now works as expected and
suspend/resumes just fine.
The MSI registers were programmed on resume, so I'm quite sure which
extra bit needs to be fiddled to ensure that MSI works as well.
The patch I'm testing with now is below, it works but of course it a
hack in areas. I'm attaching the output from resume with the debug stuff
in, in case it helps anyone.
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index f252253..f0f3a9e 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1119,6 +1119,10 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (ahci_sb600_enable_64bit(pdev))
hpriv->flags &= ~AHCI_HFLAG_32BIT_ONLY;
+ /* turn off msi on mbp 6,2 ahci mode */
+ if (pdev->device == 0x3b29)
+ hpriv->flags |= AHCI_HFLAG_NO_MSI;
+
if ((hpriv->flags & AHCI_HFLAG_NO_MSI) || pci_enable_msi(pdev))
pci_intx(pdev, 1);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index f4adba2..45e37b9 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -118,7 +118,7 @@ static inline unsigned int pci_calc_resource_flags(unsigned int flags)
return IORESOURCE_MEM;
}
-static u64 pci_size(u64 base, u64 maxbase, u64 mask)
+u64 pci_size(u64 base, u64 maxbase, u64 mask)
{
u64 size = mask & maxbase; /* Find the significant bits */
if (!size)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 477345d..f153749 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -1020,6 +1020,205 @@ static void quirk_disable_pxb(struct pci_dev *pdev)
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454NX, quirk_disable_pxb);
DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454NX, quirk_disable_pxb);
+struct pch_reg {
+ unsigned int offset;
+ unsigned int size;
+ const char *name;
+};
+
+static struct pch_reg pch_regs[] = {
+ {
+ .offset = 0x09,
+ .size = 1,
+ .name = "PI",
+ },
+ {
+ .offset = 0x0a,
+ .size = 1,
+ .name = "SCC",
+ },
+ {
+ .offset = 0x3c,
+ .size = 1,
+ .name = "INT_LN",
+ },
+ {
+ .offset = 0x3d,
+ .size = 1,
+ .name = "INT_PN",
+ },
+ {
+ .offset = 0x74,
+ .size = 2,
+ .name = "PMCS",
+ },
+ {
+ .offset = 0x82,
+ .size = 2,
+ .name = "MSIMC",
+ },
+ {
+ .offset = 0x84,
+ .size = 4,
+ .name = "MSIMA",
+ },
+ {
+ .offset = 0x88,
+ .size = 2,
+ .name = "MSIMD",
+ },
+ {
+ .offset = 0x90,
+ .size = 2,
+ .name = "MAP",
+ },
+ {
+ .offset = 0x92,
+ .size = 2,
+ .name = "PCS",
+ },
+ {
+ .offset = 0x94,
+ .size = 4,
+ .name = "SCLKCG",
+ },
+ {
+ .offset = 0x9c,
+ .size = 4,
+ .name = "SCLKGC",
+ },
+ {
+ .name = NULL,
+ },
+};
+
+static void dump_regs(struct pci_dev *pdev, const char *msg)
+{
+ struct pch_reg *pr;
+ u8 byte;
+ u16 word;
+ u32 dword;
+ int i;
+
+ printk("%s:\n", msg);
+ for (i = 0; pch_regs[i].name; i++) {
+ int val;
+
+ pr = &pch_regs[i];
+ switch (pr->size) {
+ case 1:
+ pci_read_config_byte(pdev, pr->offset, &byte);
+ val = byte;
+ break;
+ case 2:
+ pci_read_config_word(pdev, pr->offset, &word);
+ val = word;
+ break;
+ case 4:
+ pci_read_config_dword(pdev, pr->offset, &dword);
+ val = dword;
+ break;
+ default:
+ val = -1;
+ }
+ printk(" reg %s(%x): %x\n", pr->name, pr->offset, val);
+ }
+}
+
+static void show_regions(struct pci_dev *pdev, const char *msg)
+{
+ int i;
+
+ printk("%s: \n", msg);
+ for (i = 0; i <= 5; i++)
+ printk(" BAR %d, res %pR\n", i, &pdev->resource[i]);
+
+}
+
+/*
+ * This enables AHCI mode on Macbook Pro 6,2 and others based on Intels
+ * 5 series / 3400 series chipset.
+ *
+ * Info found here http://www.intel.com/Assets/PDF/datasheet/322169.pdf
+ */
+static void quirk_pch_ahci(struct pci_dev *pdev)
+{
+ u16 mode;
+
+ /*
+ * 0x90 is the MAP register offset
+ */
+ pci_read_config_word(pdev, 0x90, &mode);
+
+ /*
+ * MAP.MV must be 0x00 to allow ahci enable
+ */
+ if (mode & 0x03)
+ return;
+
+ /*
+ * Already in AHCI mode?
+ */
+ if (mode & (1 << 6))
+ return;
+
+ /*
+ * MAP.SMS bit 6 is AHCI mode, MAP.SC bit 5 is port config
+ */
+ mode = (1 << 6) | (1 << 5);
+ pci_write_config_word(pdev, 0x90, mode);
+
+ if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE ||
+ (pdev->class >> 8) == PCI_CLASS_STORAGE_SATA_AHCI) {
+ pci_write_config_byte(pdev, PCI_CLASS_PROG, 0x01);
+ pci_write_config_byte(pdev, PCI_CLASS_DEVICE, 0x06);
+ pdev->class = PCI_CLASS_STORAGE_SATA_AHCI;
+ }
+
+ /*
+ * Re-read device id, it has now changed
+ */
+ pci_read_config_word(pdev, PCI_DEVICE_ID, &pdev->device);
+
+ dump_regs(pdev, "boot");
+ show_regions(pdev, "boot");
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x3b28, quirk_pch_ahci);
+
+static void pch_update_bar(struct pci_dev *pdev)
+{
+ if (pcim_iomap_regions(pdev, 1 << 5, "AHCI quirk")) {
+ int ret;
+
+ printk("AHCI BAR not set - attempting to program... ");
+ pdev->resource[5].flags = IORESOURCE_MEM;
+ ret = pci_allocate_resource(pdev, 5);
+ if (ret)
+ printk (KERN_INFO "Failed to allocate new region\n");
+ else
+ printk (KERN_INFO "Succeeded\n");
+ } else
+ pcim_iounmap_regions(pdev, 1 << 5);
+}
+
+static void quirk_pch_ahci_resume(struct pci_dev *pdev)
+{
+ show_regions(pdev, "resume");
+ dump_regs(pdev, "resume-pre");
+
+ quirk_pch_ahci(pdev);
+#if 0
+ pci_write_config_word(pdev, 0x74, 1 << 8);
+ pci_write_config_dword(pdev, 0x94, 0x3c000183);
+ pci_write_config_dword(pdev, 0x84, 0x00);
+ pci_write_config_word(pdev, 0x88, 0x00);
+#endif
+
+ dump_regs(pdev, "resume-post");
+ pch_update_bar(pdev);
+}
+DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL, 0x3b29, quirk_pch_ahci_resume);
+
static void __devinit quirk_amd_ide_mode(struct pci_dev *pdev)
{
/* set SBX00/Hudson-2 SATA in IDE mode to AHCI mode */
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 92379e2..3255dd6 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -25,6 +25,59 @@
#include <linux/slab.h>
#include "pci.h"
+int pci_allocate_resource(struct pci_dev *dev, int resno)
+{
+ int err;
+ u32 size, mask, reg;
+ resource_size_t start;
+ struct resource *res = &dev->resource[resno];
+ struct resource *bres = pci_find_parent_resource(dev, res);
+
+ if (!bres) {
+ BUG();
+ }
+
+ if (!bres)
+ return -ENOMEM;
+
+ if (res->flags & IORESOURCE_IO) {
+ mask = (u32)PCI_BASE_ADDRESS_IO_MASK;
+ start = PCIBIOS_MIN_IO;
+ } else {
+ mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
+ start = PCIBIOS_MIN_MEM;
+ }
+
+ if (resno < 6)
+ reg = PCI_BASE_ADDRESS_0 + 4 * resno;
+ else
+ return -EINVAL;
+
+ pci_write_config_dword(dev, reg, ~0);
+ pci_read_config_dword(dev, reg, &size);
+
+ if (!size || size == 0xffffffff)
+ return 0;
+
+ size = pci_size(0, size, mask);
+
+ if (res->start != 0 && res->end != 0)
+ release_resource (res);
+
+ err = allocate_resource (bres, res, size+1, start, ~0U, 1024, NULL,
+ NULL);
+
+ if (err) {
+ printk ("Failed to allocate a resource\n");
+ return err;
+ }
+
+ pci_update_resource(dev, resno);
+
+ return 0;
+}
+EXPORT_SYMBOL(pci_allocate_resource);
+
void pci_update_resource(struct pci_dev *dev, int resno)
{
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 7cb0084..4385c9d 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -849,6 +849,8 @@ void pdev_sort_resources(struct pci_dev *, struct resource_list *);
int pci_enable_resources(struct pci_dev *, int mask);
void pci_fixup_irqs(u8 (*)(struct pci_dev *, u8 *),
int (*)(struct pci_dev *, u8, u8));
+int pci_allocate_resource(struct pci_dev *dev, int resno);
+u64 pci_size(u64 base, u64 maxbase, u64 mask);
#define HAVE_PCI_REQ_REGIONS 2
int __must_check pci_request_regions(struct pci_dev *, const char *);
int __must_check pci_request_regions_exclusive(struct pci_dev *, const char *);
--
Jens Axboe
On Sun, Jul 18, 2010 at 14:34:46 -0600, Jens Axboe wrote:
[...]
> See this is where I'm getting confused, since I'm not entirely sure what
> the boot process is. If I boot a DVD directly, then it's in piix mode.
> Booting through refit -> Linux, it's in piix mode. So my logic was that
> it is probably getting switched into ahci mode by the OSX boot loader or
> perhaps the driver does it there.
If this helps: I switched from grub-pc to grub-efi on my oldish Mac
mini Core 2 Duo (i945 chipset) and the hard disk used AHCI after this.
Suspend also works fine. So I would guess that the AHCI/PIIX difference
is caused by booting with EFI/legacy DOS bootblock, and the latter is
just done for Windows compatibility.
Regards,
Tino
Hello,
On 07/19/2010 02:25 AM, Jens Axboe wrote:
> +static void pch_update_bar(struct pci_dev *pdev)
> +{
> + if (pcim_iomap_regions(pdev, 1 << 5, "AHCI quirk")) {
> + int ret;
> +
> + printk("AHCI BAR not set - attempting to program... ");
> + pdev->resource[5].flags = IORESOURCE_MEM;
> + ret = pci_allocate_resource(pdev, 5);
> + if (ret)
> + printk (KERN_INFO "Failed to allocate new region\n");
> + else
> + printk (KERN_INFO "Succeeded\n");
> + } else
> + pcim_iounmap_regions(pdev, 1 << 5);
> +}
Hmm... as the firmware is setting up the resource during boot,
wouldn't it be better to save it and restore it during resume? That
would be simpler and more robust.
Thanks.
--
tejun
On 07/18/2010 11:40 PM, Tino Keitel wrote:
> On Sun, Jul 18, 2010 at 14:34:46 -0600, Jens Axboe wrote:
>
> [...]
>
>> See this is where I'm getting confused, since I'm not entirely sure what
>> the boot process is. If I boot a DVD directly, then it's in piix mode.
>> Booting through refit -> Linux, it's in piix mode. So my logic was that
>> it is probably getting switched into ahci mode by the OSX boot loader or
>> perhaps the driver does it there.
>
> If this helps: I switched from grub-pc to grub-efi on my oldish Mac
> mini Core 2 Duo (i945 chipset) and the hard disk used AHCI after this.
> Suspend also works fine. So I would guess that the AHCI/PIIX difference
> is caused by booting with EFI/legacy DOS bootblock, and the latter is
> just done for Windows compatibility.
Great! That sounds way better. DO you have a pointer to grub-efi? I'm
finding some grub2 efi stuff with google, just want to make sure that is
it. A grub 0.9x with efi would be preferable, I find grub2 to be horrible
to work with in general...
--
Jens Axboe
On Mon, Jul 19, 2010 at 09:49:49 -0600, Jens Axboe wrote:
[...]
> Great! That sounds way better. DO you have a pointer to grub-efi? I'm
> finding some grub2 efi stuff with google, just want to make sure that is
> it. A grub 0.9x with efi would be preferable, I find grub2 to be horrible
> to work with in general...
With grub-efi I meant the EFI support in grub2. AFAIK grub 0.9x never
supported EFI.
What information do you need?
Regards,
Tino
On 07/19/2010 09:53 AM, Tino Keitel wrote:
> On Mon, Jul 19, 2010 at 09:49:49 -0600, Jens Axboe wrote:
>
> [...]
>
>> Great! That sounds way better. DO you have a pointer to grub-efi? I'm
>> finding some grub2 efi stuff with google, just want to make sure that is
>> it. A grub 0.9x with efi would be preferable, I find grub2 to be horrible
>> to work with in general...
>
> With grub-efi I meant the EFI support in grub2. AFAIK grub 0.9x never
> supported EFI.
>
> What information do you need?
Just that, if there was some special grub 0.9x efi variant or whether
you meant grub2 when you said grub-efi.
I'll give it a spin here.
--
Jens Axboe
On Sun, Jul 18, 2010 at 06:44:41PM -0400, Jeff Garzik wrote:
> I would have quirked AHCI/piix hardware into AHCI mode long ago, if
> firmwares defaulting to piix mode would actually program the PCI BAR
> correctly.
If you perform the fixup early enough then the PCI resource allocation
code should take a decent stab at it. I'd feel more comfortable with
that once we start using ACPI _CRS by default, since that gives us a
much better chance of avoiding conflicting with some bit of motherboard
hardware.
--
Matthew Garrett | [email protected]
On Mon, Jul 19, 2010 at 11:55 AM, Jens Axboe <[email protected]> wrote:
> On 07/19/2010 09:53 AM, Tino Keitel wrote:
>> On Mon, Jul 19, 2010 at 09:49:49 -0600, Jens Axboe wrote:
>>
>> [...]
>>
>>> Great! That sounds way better. DO you have a pointer to grub-efi? I'm
>>> finding some grub2 efi stuff with google, just want to make sure that is
>>> it. A grub 0.9x with efi would be preferable, I find grub2 to be horrible
>>> to work with in general...
>>
>> With grub-efi I meant the EFI support in grub2. AFAIK grub 0.9x never
>> supported EFI.
>>
>> What information do you need?
>
> Just that, if there was some special grub 0.9x efi variant or whether
> you meant grub2 when you said grub-efi.
Fedora's grub 0.9x has efi support.
But that efi support hasn't been propagated to all the other distros
since grub 0.9x really doesn't have an upstream.
Mike
On 07/19/2010 11:23 AM, Mike Snitzer wrote:
> On Mon, Jul 19, 2010 at 11:55 AM, Jens Axboe <[email protected]> wrote:
>> On 07/19/2010 09:53 AM, Tino Keitel wrote:
>>> On Mon, Jul 19, 2010 at 09:49:49 -0600, Jens Axboe wrote:
>>>
>>> [...]
>>>
>>>> Great! That sounds way better. DO you have a pointer to grub-efi? I'm
>>>> finding some grub2 efi stuff with google, just want to make sure that is
>>>> it. A grub 0.9x with efi would be preferable, I find grub2 to be horrible
>>>> to work with in general...
>>>
>>> With grub-efi I meant the EFI support in grub2. AFAIK grub 0.9x never
>>> supported EFI.
>>>
>>> What information do you need?
>>
>> Just that, if there was some special grub 0.9x efi variant or whether
>> you meant grub2 when you said grub-efi.
>
> Fedora's grub 0.9x has efi support.
>
> But that efi support hasn't been propagated to all the other distros
> since grub 0.9x really doesn't have an upstream.
This is Fedora 13. What magic do I need to enable the EFI grub bits
then?
--
Jens Axboe