* [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
@ 2006-06-26 21:19 Edgar Hucek
2006-06-26 21:33 ` Linus Torvalds
0 siblings, 1 reply; 29+ messages in thread
From: Edgar Hucek @ 2006-06-26 21:19 UTC (permalink / raw)
To: LKML; +Cc: akpm, torvalds
Fix EFI boot on 32 bit machines with PCI Express slots.
Efi machines does not have an e820 memory map.
Without this patch a native EFI boot, on
Intel Macs, is impossible.
Signed-off-by: Edgar Hucek <hostmaster@ed-soft.at>
--- a/arch/i386/kernel/setup.c 2006-06-25 03:13:24.000000000 +0200
+++ b/arch/i386/kernel/setup.c 2006-06-25 03:13:50.000000000 +0200
@@ -975,6 +975,10 @@
u64 start = s;
u64 end = e;
int i;
+
+ if (efi_enabled)
+ return 1;
+
for (i = 0; i < e820.nr_map; i++) {
struct e820entry *ei = &e820.map[i];
if (type && ei->type != type)
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
2006-06-26 21:19 [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4] Edgar Hucek
@ 2006-06-26 21:33 ` Linus Torvalds
2006-06-27 6:15 ` Edgar Hucek
0 siblings, 1 reply; 29+ messages in thread
From: Linus Torvalds @ 2006-06-26 21:33 UTC (permalink / raw)
To: Edgar Hucek; +Cc: LKML, akpm
On Mon, 26 Jun 2006, Edgar Hucek wrote:
>
> Fix EFI boot on 32 bit machines with PCI Express slots.
> Efi machines does not have an e820 memory map.
The EFI code really should fill in the e820 memory map instead fo making
up its own routines (and doing it badly at that).
There's nothing wrong with the e820 table, and we should consider it just
the "firmware memory map", and not care how it's filled in (whether it's
EFI or a real e820 BIOS call).
Quite frankly, right now I'm more likely to rip out the EFI code than
start adding even more (broken) support for it.
On the Intel Macs, upgrading the firmware turns it into a perfectly usable
machine.
Linus
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
2006-06-26 21:33 ` Linus Torvalds
@ 2006-06-27 6:15 ` Edgar Hucek
2006-06-27 6:20 ` Linus Torvalds
0 siblings, 1 reply; 29+ messages in thread
From: Edgar Hucek @ 2006-06-27 6:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: LKML, akpm
So what is your suggestion to get the working funktionality
from kernel 2.6.16 back ? 2.6.17 have broken it.
Sure, using Apples legacy support for EFI is a method to
boot linux on the Intel Macs, but not the native way. It depends
on how good their legacy emulation is and if they implement it
in future products. They could also decide to drop it.
cu
Edgar (gimli) Hucek
Linus Torvalds schrieb:
>
> On Mon, 26 Jun 2006, Edgar Hucek wrote:
>> Fix EFI boot on 32 bit machines with PCI Express slots.
>> Efi machines does not have an e820 memory map.
>
> The EFI code really should fill in the e820 memory map instead fo making
> up its own routines (and doing it badly at that).
>
> There's nothing wrong with the e820 table, and we should consider it just
> the "firmware memory map", and not care how it's filled in (whether it's
> EFI or a real e820 BIOS call).
>
> Quite frankly, right now I'm more likely to rip out the EFI code than
> start adding even more (broken) support for it.
>
> On the Intel Macs, upgrading the firmware turns it into a perfectly usable
> machine.
>
> Linus
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
2006-06-27 6:15 ` Edgar Hucek
@ 2006-06-27 6:20 ` Linus Torvalds
2006-06-28 22:37 ` H. Peter Anvin
0 siblings, 1 reply; 29+ messages in thread
From: Linus Torvalds @ 2006-06-27 6:20 UTC (permalink / raw)
To: Edgar Hucek; +Cc: LKML, akpm
On Tue, 27 Jun 2006, Edgar Hucek wrote:
>
> So what is your suggestion to get the working funktionality
> from kernel 2.6.16 back ? 2.6.17 have broken it.
I'd really suggest just filling in the e820 table from the EFI information
early at boot.
(Even better would be for the EFI bootloader on x86 to just fill things in
_as_if_ it was filling in e820 data, but that's outside of the kernel, so
if you want the _kernel_ to be able to handle native EFI data, do it by
just translating it once into e820 mode, and you're done).
The translation from EFI to e820 format should be very straightforward
indeed. I think it's pretty much the same thing with different naming.
Linus
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
2006-06-27 6:20 ` Linus Torvalds
@ 2006-06-28 22:37 ` H. Peter Anvin
2006-07-02 17:39 ` Eric W. Biederman
0 siblings, 1 reply; 29+ messages in thread
From: H. Peter Anvin @ 2006-06-28 22:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Edgar Hucek, LKML, akpm
Linus Torvalds wrote:
>
> On Tue, 27 Jun 2006, Edgar Hucek wrote:
>> So what is your suggestion to get the working funktionality
>> from kernel 2.6.16 back ? 2.6.17 have broken it.
>
> I'd really suggest just filling in the e820 table from the EFI information
> early at boot.
>
> (Even better would be for the EFI bootloader on x86 to just fill things in
> _as_if_ it was filling in e820 data, but that's outside of the kernel, so
> if you want the _kernel_ to be able to handle native EFI data, do it by
> just translating it once into e820 mode, and you're done).
>
> The translation from EFI to e820 format should be very straightforward
> indeed. I think it's pretty much the same thing with different naming.
>
You probably don't want to put it in the bootloader. The kernel is
easier to upgrade than the bootloader, which is easier to upgrade than
the firmware, so it makes more sense for the kernel to be as
self-sufficient as is possible, or at least practical.
-hpa
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
2006-06-28 22:37 ` H. Peter Anvin
@ 2006-07-02 17:39 ` Eric W. Biederman
2006-07-02 17:42 ` H. Peter Anvin
0 siblings, 1 reply; 29+ messages in thread
From: Eric W. Biederman @ 2006-07-02 17:39 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, Edgar Hucek, LKML, akpm
"H. Peter Anvin" <hpa@zytor.com> writes:
> Linus Torvalds wrote:
>> On Tue, 27 Jun 2006, Edgar Hucek wrote:
>>> So what is your suggestion to get the working funktionality
>>> from kernel 2.6.16 back ? 2.6.17 have broken it.
>> I'd really suggest just filling in the e820 table from the EFI information
>> early at boot.
>> (Even better would be for the EFI bootloader on x86 to just fill things in
>> _as_if_ it was filling in e820 data, but that's outside of the kernel, so if
>> you want the _kernel_ to be able to handle native EFI data, do it by just
>> translating it once into e820 mode, and you're done).
>> The translation from EFI to e820 format should be very straightforward
>> indeed. I think it's pretty much the same thing with different naming.
>>
>
> You probably don't want to put it in the bootloader. The kernel is easier to
> upgrade than the bootloader, which is easier to upgrade than the firmware, so it
> makes more sense for the kernel to be as self-sufficient as is possible, or at
> least practical.
Regardless it would be nice if the efi implementation hacks were removed.
My favorite is this one in init/main.c
#ifdef CONFIG_X86
if (efi_enabled)
efi_enter_virtual_mode();
#endif
Which pretty much guarantees efi won't be a distro supported feature
any time soon because it breaks kexec the ability of a kexec'd kernel
to boot and thus crash dump support. Or it does if you ever use efi
callbacks, and if you don't use efi callbacks there is no point in
calling that function. Why are efi callbacks not always done in
physical mode?
Eric
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
2006-07-02 17:39 ` Eric W. Biederman
@ 2006-07-02 17:42 ` H. Peter Anvin
2006-07-02 18:26 ` Eric W. Biederman
0 siblings, 1 reply; 29+ messages in thread
From: H. Peter Anvin @ 2006-07-02 17:42 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Linus Torvalds, Edgar Hucek, LKML, akpm
Eric W. Biederman wrote:
>>>
>> You probably don't want to put it in the bootloader. The kernel is easier to
>> upgrade than the bootloader, which is easier to upgrade than the firmware, so it
>> makes more sense for the kernel to be as self-sufficient as is possible, or at
>> least practical.
>
> Regardless it would be nice if the efi implementation hacks were removed.
>
> My favorite is this one in init/main.c
> #ifdef CONFIG_X86
> if (efi_enabled)
> efi_enter_virtual_mode();
> #endif
>
> Which pretty much guarantees efi won't be a distro supported feature
> any time soon because it breaks kexec the ability of a kexec'd kernel
> to boot and thus crash dump support. Or it does if you ever use efi
> callbacks, and if you don't use efi callbacks there is no point in
> calling that function. Why are efi callbacks not always done in
> physical mode?
>
If nothing else, they should be isolated, and in the early kernel build
a datastructure like the e820 data structure, so the downstream kernel
doesn't deal with it.
I have no idea what the above does; it sounds to me like something that
should be possible to do differently, though.
-hpa
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
2006-07-02 17:42 ` H. Peter Anvin
@ 2006-07-02 18:26 ` Eric W. Biederman
2006-07-02 18:46 ` Arjan van de Ven
2006-07-05 9:38 ` Edgar Hucek
0 siblings, 2 replies; 29+ messages in thread
From: Eric W. Biederman @ 2006-07-02 18:26 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, Edgar Hucek, LKML, akpm
"H. Peter Anvin" <hpa@zytor.com> writes:
> Eric W. Biederman wrote:
>
>>>>
>>> You probably don't want to put it in the bootloader. The kernel is easier to
>>> upgrade than the bootloader, which is easier to upgrade than the firmware, so
> it
>>> makes more sense for the kernel to be as self-sufficient as is possible, or
> at
>>> least practical.
>> Regardless it would be nice if the efi implementation hacks were removed.
>>
>> My favorite is this one in init/main.c #ifdef CONFIG_X86
>> if (efi_enabled)
>> efi_enter_virtual_mode();
>> #endif
>> Which pretty much guarantees efi won't be a distro supported feature
>> any time soon because it breaks kexec the ability of a kexec'd kernel
>> to boot and thus crash dump support. Or it does if you ever use efi
>> callbacks, and if you don't use efi callbacks there is no point in
>> calling that function. Why are efi callbacks not always done in
>> physical mode?
>>
>
> If nothing else, they should be isolated, and in the early kernel build a
> datastructure like the e820 data structure, so the downstream kernel doesn't
> deal with it.
>
> I have no idea what the above does; it sounds to me like something that should
> be possible to do differently, though.
Quite.
The part that is an obvious hack is that it shows up in init/main.c
for no apparent reason. Instead of being in architecture specific code
since it only applies to one architecture. ia64 which also uses efi
doesn't need to patch init/main.c
Basically this was just an example to add to the e820 map problem of what
a problem this code really is.
Thinking about the e820 problem. That is in the function:
e820_all_mapped(unsigned long s, unsigned long e, unsigned type)
Which is a test. I believe this is the sanity check to ensure the
pci express memory mapped configuration area is accessible.
In which case disabling the test is totally wrong,
and I agree with Linus that we need to convert the structure.
We need to know what the BIOS's idea of the memory map is and to be
able to query it.
Although I am surprised we could not just make that query by looking
at the resources. Possibly we are too early in boot.
Eric
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
2006-07-02 18:26 ` Eric W. Biederman
@ 2006-07-02 18:46 ` Arjan van de Ven
2006-07-05 9:38 ` Edgar Hucek
1 sibling, 0 replies; 29+ messages in thread
From: Arjan van de Ven @ 2006-07-02 18:46 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: H. Peter Anvin, Linus Torvalds, Edgar Hucek, LKML, akpm
> Although I am surprised we could not just make that query by looking
> at the resources. Possibly we are too early in boot.
the problem in this specific case is that you try to compare the
resource info (more or less, indirectly) to the memory map, and abort if
there's a discrepancy, as a sanity check against b0rked bioses.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
2006-07-02 18:26 ` Eric W. Biederman
2006-07-02 18:46 ` Arjan van de Ven
@ 2006-07-05 9:38 ` Edgar Hucek
2006-07-05 15:52 ` Eric W. Biederman
1 sibling, 1 reply; 29+ messages in thread
From: Edgar Hucek @ 2006-07-05 9:38 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: H. Peter Anvin, Linus Torvalds, LKML, akpm
I agre with you to make efi use the e820 map as a long term solution.
But at the moment the efi part is completley broken without my patch.
At least on Intel Macs.
Without the patch also my Imacfb driver makes no sense, since it is
for efi booted Intel Macs.
cu
Edgar (gimli) Hucek
Eric W. Biederman schrieb:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>> Eric W. Biederman wrote:
>>
>>>> You probably don't want to put it in the bootloader. The kernel is easier to
>>>> upgrade than the bootloader, which is easier to upgrade than the firmware, so
>> it
>>>> makes more sense for the kernel to be as self-sufficient as is possible, or
>> at
>>>> least practical.
>>> Regardless it would be nice if the efi implementation hacks were removed.
>>>
>>> My favorite is this one in init/main.c #ifdef CONFIG_X86
>>> if (efi_enabled)
>>> efi_enter_virtual_mode();
>>> #endif
>>> Which pretty much guarantees efi won't be a distro supported feature
>>> any time soon because it breaks kexec the ability of a kexec'd kernel
>>> to boot and thus crash dump support. Or it does if you ever use efi
>>> callbacks, and if you don't use efi callbacks there is no point in
>>> calling that function. Why are efi callbacks not always done in
>>> physical mode?
>>>
>> If nothing else, they should be isolated, and in the early kernel build a
>> datastructure like the e820 data structure, so the downstream kernel doesn't
>> deal with it.
>>
>> I have no idea what the above does; it sounds to me like something that should
>> be possible to do differently, though.
>
> Quite.
>
> The part that is an obvious hack is that it shows up in init/main.c
> for no apparent reason. Instead of being in architecture specific code
> since it only applies to one architecture. ia64 which also uses efi
> doesn't need to patch init/main.c
>
> Basically this was just an example to add to the e820 map problem of what
> a problem this code really is.
>
> Thinking about the e820 problem. That is in the function:
> e820_all_mapped(unsigned long s, unsigned long e, unsigned type)
>
> Which is a test. I believe this is the sanity check to ensure the
> pci express memory mapped configuration area is accessible.
>
> In which case disabling the test is totally wrong,
> and I agree with Linus that we need to convert the structure.
>
> We need to know what the BIOS's idea of the memory map is and to be
> able to query it.
>
> Although I am surprised we could not just make that query by looking
> at the resources. Possibly we are too early in boot.
>
> Eric
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
2006-07-05 9:38 ` Edgar Hucek
@ 2006-07-05 15:52 ` Eric W. Biederman
2006-07-13 21:46 ` Edgar Hucek
0 siblings, 1 reply; 29+ messages in thread
From: Eric W. Biederman @ 2006-07-05 15:52 UTC (permalink / raw)
To: Edgar Hucek; +Cc: H. Peter Anvin, Linus Torvalds, LKML, akpm
Edgar Hucek <hostmaster@ed-soft.at> writes:
> I agre with you to make efi use the e820 map as a long term solution.
> But at the moment the efi part is completley broken without my patch.
But your patch isn't a fix. It is a hack to make the system boot.
A patch that performed the same check on the efi memory map,
or it converted the efi memory map to use an e820 map it would be a fix.
> At least on Intel Macs.
> Without the patch also my Imacfb driver makes no sense, since it is
> for efi booted Intel Macs.
My point is that the kernel efi support is broken. You have just found
the location where the bone is poking through the skin.
I am tempted to write a patch to delete the x86 efi support at this
point. So that it is very clear that it needs to be completely redone.
Eric
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
2006-07-05 15:52 ` Eric W. Biederman
@ 2006-07-13 21:46 ` Edgar Hucek
2006-07-13 22:15 ` Linus Torvalds
0 siblings, 1 reply; 29+ messages in thread
From: Edgar Hucek @ 2006-07-13 21:46 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: H. Peter Anvin, Linus Torvalds, LKML, akpm
I converted the efi memory map to use the e820 table.
While converting i discovered why the kernel would allways
fail to boot through efi on Intel Macs without a proper fix.
>From kernel 2.6.16 to kernel 2.6.17 a new check is made.
File arch/i386/pci/mmconfig.c -> funktion pci_mmcfg_init -> check e820_all_mapped
The courios thing is that this check will always fail on the
Intel Macs booted through efi. Parsing of the ACPI_MCFG table
returns e0000000 for the start. But this location is
not in the memory map which the efi firmware have :
BIOS-EFI: 00000000e00f8000 - 00000000e00f9000 (reserved)
So the e820_all_mapped would allways fail.
Anny suggestions how to fix this problem ? Maybe some kind
of whitelisting, using dmi_check_system ?
cu
Edgar Hucek
Eric W. Biederman schrieb:
> Edgar Hucek <hostmaster@ed-soft.at> writes:
>
>> I agre with you to make efi use the e820 map as a long term solution.
>> But at the moment the efi part is completley broken without my patch.
>
> But your patch isn't a fix. It is a hack to make the system boot.
>
> A patch that performed the same check on the efi memory map,
> or it converted the efi memory map to use an e820 map it would be a fix.
>
>> At least on Intel Macs.
>> Without the patch also my Imacfb driver makes no sense, since it is
>> for efi booted Intel Macs.
>
> My point is that the kernel efi support is broken. You have just found
> the location where the bone is poking through the skin.
>
> I am tempted to write a patch to delete the x86 efi support at this
> point. So that it is very clear that it needs to be completely redone.
>
> Eric
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
2006-07-13 21:46 ` Edgar Hucek
@ 2006-07-13 22:15 ` Linus Torvalds
2006-07-14 4:23 ` Eric W. Biederman
2006-07-14 6:20 ` Edgar Hucek
0 siblings, 2 replies; 29+ messages in thread
From: Linus Torvalds @ 2006-07-13 22:15 UTC (permalink / raw)
To: Edgar Hucek; +Cc: Eric W. Biederman, H. Peter Anvin, LKML, akpm
On Thu, 13 Jul 2006, Edgar Hucek wrote:
>
> I converted the efi memory map to use the e820 table.
> While converting i discovered why the kernel would allways
> fail to boot through efi on Intel Macs without a proper fix.
Ok, can you show what the converted and the original map looks like?
> From kernel 2.6.16 to kernel 2.6.17 a new check is made.
> File arch/i386/pci/mmconfig.c -> funktion pci_mmcfg_init -> check e820_all_mapped
> The courios thing is that this check will always fail on the
> Intel Macs booted through efi. Parsing of the ACPI_MCFG table
> returns e0000000 for the start. But this location is
> not in the memory map which the efi firmware have :
> BIOS-EFI: 00000000e00f8000 - 00000000e00f9000 (reserved)
It _sounds_ like you may not have converted all the EFI types
(EFI_UNUSABLE_MEMORY?), but regardless, I think it would be fine to have
perhaps a "PCI_FORCE_MMCONF" flag that avoided that sanity check, and then
you could have some code (either the EFI code _or_ some DMI code) that
sets it for the Intel Macs.
Note that the check in pci_mmcfg_init() shouldn't be some EFI hack itself,
it would be a real flag for the PCI subsystem, independently of EFI (I can
see it being useful for a kernel command line option, even), and the only
EFI connection would be that perhaps the EFI code ends up setting that
flag (especially if there is some EFI command for doing this).
Btw, if you do do this, I think we should make sure that the MMCONFIG base
address is reserved in the PCI MMIO resource structures (which we don't do
now, I think - part of the whole point of verifying that it's marked as
E820_RESERVED is exactly the fact that otherwise we migth have problems
with PCI MMIO resource allocations allocating a regular PCI resource over
the MMCONFIG space..)
Linus
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
2006-07-13 22:15 ` Linus Torvalds
@ 2006-07-14 4:23 ` Eric W. Biederman
2006-07-14 6:22 ` H. Peter Anvin
2006-07-14 6:20 ` Edgar Hucek
1 sibling, 1 reply; 29+ messages in thread
From: Eric W. Biederman @ 2006-07-14 4:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Edgar Hucek, H. Peter Anvin, LKML, akpm
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 13 Jul 2006, Edgar Hucek wrote:
>>
>> I converted the efi memory map to use the e820 table.
>> While converting i discovered why the kernel would allways
>> fail to boot through efi on Intel Macs without a proper fix.
>
> Ok, can you show what the converted and the original map looks like?
>
>> From kernel 2.6.16 to kernel 2.6.17 a new check is made.
>> File arch/i386/pci/mmconfig.c -> funktion pci_mmcfg_init -> check
> e820_all_mapped
>> The courios thing is that this check will always fail on the
>> Intel Macs booted through efi. Parsing of the ACPI_MCFG table
>> returns e0000000 for the start. But this location is
>> not in the memory map which the efi firmware have :
>> BIOS-EFI: 00000000e00f8000 - 00000000e00f9000 (reserved)
>
> It _sounds_ like you may not have converted all the EFI types
> (EFI_UNUSABLE_MEMORY?), but regardless, I think it would be fine to have
> perhaps a "PCI_FORCE_MMCONF" flag that avoided that sanity check, and then
> you could have some code (either the EFI code _or_ some DMI code) that
> sets it for the Intel Macs.
>
> Note that the check in pci_mmcfg_init() shouldn't be some EFI hack itself,
> it would be a real flag for the PCI subsystem, independently of EFI (I can
> see it being useful for a kernel command line option, even), and the only
> EFI connection would be that perhaps the EFI code ends up setting that
> flag (especially if there is some EFI command for doing this).
>
> Btw, if you do do this, I think we should make sure that the MMCONFIG base
> address is reserved in the PCI MMIO resource structures (which we don't do
> now, I think - part of the whole point of verifying that it's marked as
> E820_RESERVED is exactly the fact that otherwise we migth have problems
> with PCI MMIO resource allocations allocating a regular PCI resource over
> the MMCONFIG space..)
While we are thinking about this I have a stupid question.
Currently if a memory mapped region does not fall in a standard PCI
bar we insist it must be E820 reserved. However if we E820 reserve
the memory of a standard pci bar it becomes unusable.
Is this really the behavior that we intend?
It gets confusing that E820 reserved gets double duty as memory
the BIOS is using and MMIO space that is mapped by a non-standard bar.
Eric
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
2006-07-13 22:15 ` Linus Torvalds
2006-07-14 4:23 ` Eric W. Biederman
@ 2006-07-14 6:20 ` Edgar Hucek
2006-07-14 16:09 ` Linus Torvalds
1 sibling, 1 reply; 29+ messages in thread
From: Edgar Hucek @ 2006-07-14 6:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric W. Biederman, H. Peter Anvin, LKML, akpm
This is the memory map from the efi shell :
available 0000000000000000-000000000008EFFF 000000000000008F 000000000000000F
ACPI_NVS 000000000008F000-000000000008FFFF 0000000000000001 000000000000000F
available 0000000000090000-000000000009FFFF 0000000000000010 000000000000000F
available 0000000000100000-000000007C64FFFF 000000000007C550 000000000000000F
BS_data 000000007C650000-000000007C697FFF 0000000000000048 000000000000000F
available 000000007C698000-000000007CEA9FFF 0000000000000812 000000000000000F
LoaderData 000000007CEAA000-000000007CEC2FFF 0000000000000019 000000000000000F
LoaderCode 000000007CEC3000-000000007CFD5FFF 0000000000000113 000000000000000F
LoaderData 000000007CFD6000-000000007D08DFFF 00000000000000B8 000000000000000F
LoaderCode 000000007D08E000-000000007D09EFFF 0000000000000011 000000000000000F
available 000000007D09F000-000000007D37DFFF 00000000000002DF 000000000000000F
BS_data 000000007D37E000-000000007DCF0FFF 0000000000000973 000000000000000F
available 000000007DCF1000-000000007DD2EFFF 000000000000003E 000000000000000F
BS_data 000000007DD2F000-000000007DDD7FFF 00000000000000A9 000000000000000F
available 000000007DDD8000-000000007DE10FFF 0000000000000039 000000000000000F
BS_data 000000007DE11000-000000007E0D0FFF 00000000000002C0 000000000000000F
ACPI_NVS 000000007E0D1000-000000007E2D1FFF 0000000000000201 000000000000000F
BS_data 000000007E2D2000-000000007ECEDFFF 0000000000000A1C 000000000000000F
available 000000007ECEE000-000000007ED30FFF 0000000000000043 000000000000000F
BS_code 000000007ED31000-000000007EE3FFFF 000000000000010F 000000000000000F
available 000000007EE40000-000000007EE48FFF 0000000000000009 000000000000000F
RT_code 000000007EE49000-000000007EE6EFFF 0000000000000026 800000000000000F
available 000000007EE6F000-000000007EE7EFFF 0000000000000010 000000000000000F
RT_data 000000007EE7F000-000000007EEAAFFF 000000000000002C 800000000000000F
available 000000007EEAB000-000000007EEBAFFF 0000000000000010 000000000000000F
ACPI_recl 000000007EEBB000-000000007EEBFFFF 0000000000000005 000000000000000F
available 000000007EEC0000-000000007EEC1FFF 0000000000000002 000000000000000F
ACPI_NVS 000000007EEC2000-000000007EEEEFFF 000000000000002D 000000000000000F
ACPI_recl 000000007EEEF000-000000007EEFEFFF 0000000000000010 000000000000000F
RT_data 000000007EEFF000-000000007EEFFFFF 0000000000000001 800000000000000F
MemMapIO 00000000E00F8000-00000000E00F8FFF 0000000000000001 8000000000000000
MemMapIO 00000000FED1C000-00000000FED1FFFF 0000000000000004 8000000000000000
MemMapIO 00000000FFFB0000-00000000FFFDFFFF 0000000000000030 8000000000000000
This is the Memory what the kernel efi funktions get :
mem00: type=7, attr=0xf, range=[0x0000000000000000-0x000000000008f000) (0MB)
mem01: type=10, attr=0xf, range=[0x000000000008f000-0x0000000000090000) (0MB)
mem02: type=7, attr=0xf, range=[0x0000000000090000-0x00000000000a0000) (0MB)
mem03: type=2, attr=0xf, range=[0x0000000000100000-0x0000000003300000) (50MB)
mem04: type=7, attr=0xf, range=[0x0000000003300000-0x000000007c650000) (1939MB)
mem05: type=4, attr=0xf, range=[0x000000007c650000-0x000000007c698000) (0MB)
mem06: type=7, attr=0xf, range=[0x000000007c698000-0x000000007cf9a000) (9MB)
mem07: type=2, attr=0xf, range=[0x000000007cf9a000-0x000000007cfa5000) (0MB)
mem08: type=1, attr=0xf, range=[0x000000007cfa5000-0x000000007cfd6000) (0MB)
mem09: type=2, attr=0xf, range=[0x000000007cfd6000-0x000000007d032000) (0MB)
mem10: type=1, attr=0xf, range=[0x000000007d032000-0x000000007d033000) (0MB)
mem11: type=7, attr=0xf, range=[0x000000007d033000-0x000000007d034000) (0MB)
mem12: type=2, attr=0xf, range=[0x000000007d034000-0x000000007d08e000) (0MB)
mem13: type=1, attr=0xf, range=[0x000000007d08e000-0x000000007d09f000) (0MB)
mem14: type=7, attr=0xf, range=[0x000000007d09f000-0x000000007d3bf000) (3MB)
mem15: type=4, attr=0xf, range=[0x000000007d3bf000-0x000000007dcf1000) (9MB)
mem16: type=7, attr=0xf, range=[0x000000007dcf1000-0x000000007ddc1000) (0MB)
mem17: type=4, attr=0xf, range=[0x000000007ddc1000-0x000000007e0d1000) (3MB)
mem18: type=10, attr=0xf, range=[0x000000007e0d1000-0x000000007e2d2000) (2MB)
mem19: type=4, attr=0xf, range=[0x000000007e2d2000-0x000000007ecee000) (10MB)
mem20: type=7, attr=0xf, range=[0x000000007ecee000-0x000000007ed31000) (0MB)
mem21: type=3, attr=0xf, range=[0x000000007ed31000-0x000000007ee40000) (1MB)
mem22: type=7, attr=0xf, range=[0x000000007ee40000-0x000000007ee49000) (0MB)
mem23: type=5, attr=0x800000000000000f, range=[0x000000007ee49000-0x000000007ee6f000) (0MB)
mem24: type=7, attr=0xf, range=[0x000000007ee6f000-0x000000007ee7f000) (0MB)
mem25: type=6, attr=0x800000000000000f, range=[0x000000007ee7f000-0x000000007eeab000) (0MB)
mem26: type=7, attr=0xf, range=[0x000000007eeab000-0x000000007eebb000) (0MB)
mem27: type=9, attr=0xf, range=[0x000000007eebb000-0x000000007eec0000) (0MB)
mem28: type=7, attr=0xf, range=[0x000000007eec0000-0x000000007eec2000) (0MB)
mem29: type=10, attr=0xf, range=[0x000000007eec2000-0x000000007eeef000) (0MB)
mem30: type=9, attr=0xf, range=[0x000000007eeef000-0x000000007eeff000) (0MB)
mem31: type=6, attr=0x800000000000000f, range=[0x000000007eeff000-0x000000007ef00000) (0MB)
mem32: type=11, attr=0x8000000000000000, range=[0x00000000e00f8000-0x00000000e00f9000) (0MB)
mem33: type=11, attr=0x8000000000000000, range=[0x00000000fed1c000-0x00000000fed20000) (0MB)
mem34: type=11, attr=0x8000000000000000, range=[0x00000000fffb0000-0x00000000fffe0000) (0MB)
This is the converted memory map :
BIOS-EFI: 0000000000000000 - 000000000008f000 (usable)
BIOS-EFI: 000000000008f000 - 0000000000090000 (ACPI NVS)
BIOS-EFI: 0000000000090000 - 00000000000a0000 (usable)
BIOS-EFI: 0000000003300000 - 000000007c650000 (usable)
BIOS-EFI: 000000007c698000 - 000000007cf9a000 (usable)
BIOS-EFI: 000000007d033000 - 000000007d034000 (usable)
BIOS-EFI: 000000007d09f000 - 000000007d3bf000 (usable)
BIOS-EFI: 000000007dcf1000 - 000000007ddc1000 (usable)
BIOS-EFI: 000000007e0d1000 - 000000007e2d2000 (ACPI NVS)
BIOS-EFI: 000000007ecee000 - 000000007ed31000 (usable)
BIOS-EFI: 000000007ee40000 - 000000007ee49000 (usable)
BIOS-EFI: 000000007ee6f000 - 000000007ee7f000 (usable)
BIOS-EFI: 000000007eeab000 - 000000007eebb000 (usable)
BIOS-EFI: 000000007eebb000 - 000000007eec0000 (ACPI data)
BIOS-EFI: 000000007eec0000 - 000000007eec2000 (usable)
BIOS-EFI: 000000007eec2000 - 000000007eeef000 (ACPI NVS)
BIOS-EFI: 000000007eeef000 - 000000007eeff000 (ACPI data)
BIOS-EFI: 00000000e00f8000 - 00000000e00f9000 (reserved)
BIOS-EFI: 00000000fed1c000 - 00000000fed20000 (reserved)
BIOS-EFI: 00000000fffb0000 - 00000000fffe0000 (reserved)
This is the funktion i used for converting :
void __init efi_init_e820_map(void)
{
efi_memory_desc_t *md;
unsigned long long start = 0;
unsigned long long end = 0;
unsigned long long size = 0;
void *p;
e820.nr_map = 0;
for (p = memmap.map; p < memmap.map_end;
p += memmap.desc_size) {
md = p;
switch (md->type) {
case EFI_ACPI_RECLAIM_MEMORY:
add_memory_region(md->phys_addr, md->num_pages << EFI_PAGE_SHIFT, E820_ACPI);
break;
case EFI_RESERVED_TYPE:
case EFI_MEMORY_MAPPED_IO:
case EFI_MEMORY_MAPPED_IO_PORT_SPACE:
case EFI_UNUSABLE_MEMORY:
add_memory_region(md->phys_addr, md->num_pages << EFI_PAGE_SHIFT, E820_RESERVED);
break;
case EFI_CONVENTIONAL_MEMORY:
start = md->phys_addr;
size = md->num_pages << EFI_PAGE_SHIFT;
end = start + size;
if (start < 0x100000ULL && end > 0xA0000ULL) {
if (start < 0xA0000ULL)
add_memory_region(start, 0xA0000ULL-start, E820_RAM);
if (end <= 0x100000ULL)
continue;
start = 0x100000ULL;
size = end - start;
}
add_memory_region(start, size, E820_RAM);
break;
case EFI_ACPI_MEMORY_NVS:
add_memory_region(md->phys_addr, md->num_pages << EFI_PAGE_SHIFT, E820_NVS);
break;
}
}
}
cu
Edgar Hucek
Linus Torvalds schrieb:
>
> On Thu, 13 Jul 2006, Edgar Hucek wrote:
>> I converted the efi memory map to use the e820 table.
>> While converting i discovered why the kernel would allways
>> fail to boot through efi on Intel Macs without a proper fix.
>
> Ok, can you show what the converted and the original map looks like?
>
>> From kernel 2.6.16 to kernel 2.6.17 a new check is made.
>> File arch/i386/pci/mmconfig.c -> funktion pci_mmcfg_init -> check e820_all_mapped
>> The courios thing is that this check will always fail on the
>> Intel Macs booted through efi. Parsing of the ACPI_MCFG table
>> returns e0000000 for the start. But this location is
>> not in the memory map which the efi firmware have :
>> BIOS-EFI: 00000000e00f8000 - 00000000e00f9000 (reserved)
>
> It _sounds_ like you may not have converted all the EFI types
> (EFI_UNUSABLE_MEMORY?), but regardless, I think it would be fine to have
> perhaps a "PCI_FORCE_MMCONF" flag that avoided that sanity check, and then
> you could have some code (either the EFI code _or_ some DMI code) that
> sets it for the Intel Macs.
>
> Note that the check in pci_mmcfg_init() shouldn't be some EFI hack itself,
> it would be a real flag for the PCI subsystem, independently of EFI (I can
> see it being useful for a kernel command line option, even), and the only
> EFI connection would be that perhaps the EFI code ends up setting that
> flag (especially if there is some EFI command for doing this).
>
> Btw, if you do do this, I think we should make sure that the MMCONFIG base
> address is reserved in the PCI MMIO resource structures (which we don't do
> now, I think - part of the whole point of verifying that it's marked as
> E820_RESERVED is exactly the fact that otherwise we migth have problems
> with PCI MMIO resource allocations allocating a regular PCI resource over
> the MMCONFIG space..)
>
> Linus
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
2006-07-14 4:23 ` Eric W. Biederman
@ 2006-07-14 6:22 ` H. Peter Anvin
0 siblings, 0 replies; 29+ messages in thread
From: H. Peter Anvin @ 2006-07-14 6:22 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Linus Torvalds, Edgar Hucek, LKML, akpm
Eric W. Biederman wrote:
>
> While we are thinking about this I have a stupid question.
> Currently if a memory mapped region does not fall in a standard PCI
> bar we insist it must be E820 reserved. However if we E820 reserve
> the memory of a standard pci bar it becomes unusable.
>
> Is this really the behavior that we intend?
>
> It gets confusing that E820 reserved gets double duty as memory
> the BIOS is using and MMIO space that is mapped by a non-standard bar.
>
Well, they are both really the same thing... "memory space the OS has no
idea how it works; here there be dragons."
-hpa
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]
2006-07-14 6:20 ` Edgar Hucek
@ 2006-07-14 16:09 ` Linus Torvalds
2006-07-16 8:55 ` [PATCH 1/1] Add efi e820 memory mapping on x86 [try #1] Edgar Hucek
2006-07-16 9:00 ` [PATCH 1/1] Add force of use MMCONFIG " Edgar Hucek
0 siblings, 2 replies; 29+ messages in thread
From: Linus Torvalds @ 2006-07-14 16:09 UTC (permalink / raw)
To: Edgar Hucek; +Cc: Eric W. Biederman, H. Peter Anvin, LKML, akpm
On Fri, 14 Jul 2006, Edgar Hucek wrote:
>
> This is the memory map from the efi shell :
Ok, it really looks like EFI is broken. You said that "ACPI_MCFG table
returns e0000000", ie we should find the config space thing there, yet:
> [ snip snip ... ]
> ACPI_recl 000000007EEEF000-000000007EEFEFFF 0000000000000010 000000000000000F
> RT_data 000000007EEFF000-000000007EEFFFFF 0000000000000001 800000000000000F
> MemMapIO 00000000E00F8000-00000000E00F8FFF 0000000000000001 8000000000000000
> MemMapIO 00000000FED1C000-00000000FED1FFFF 0000000000000004 8000000000000000
> MemMapIO 00000000FFFB0000-00000000FFFDFFFF 0000000000000030 8000000000000000
It clearly wasn't there..
However, it looks like your conversion is a bit buggy:
> This is the converted memory map :
>
> [ snip snip .. ]
> BIOS-EFI: 000000007eeef000 - 000000007eeff000 (ACPI data)
> BIOS-EFI: 00000000e00f8000 - 00000000e00f9000 (reserved)
> BIOS-EFI: 00000000fed1c000 - 00000000fed20000 (reserved)
> BIOS-EFI: 00000000fffb0000 - 00000000fffe0000 (reserved)
The above is missing the "RT_data" thing (which was there in your input):
mem31: type=6, attr=0x800000000000000f, range=[0x000000007eeff000-0x000000007ef00000) (0MB)
> This is the funktion i used for converting :
>
> case EFI_RESERVED_TYPE:
> case EFI_MEMORY_MAPPED_IO:
> case EFI_MEMORY_MAPPED_IO_PORT_SPACE:
> case EFI_UNUSABLE_MEMORY:
> add_memory_region(md->phys_addr, md->num_pages << EFI_PAGE_SHIFT, E820_RESERVED);
> break;
I think that should be a "default:", to make sure that you don't have any
memory region types that get ignored. Because it looks like you missed the
EFI_RUNTIME_SERVICES_CODE/EFI_RUNTIME_SERVICES_DATA ones at a minimum (an
dmaybe others - I didn't check).
Anyway, that won't fix your bug, and yes, it sounds like you should add a
PCI_PROBE_FORCE_MMCFG flag (and then do the proper MMIO region reservation
to make sure that we don't allocate over it when allocating PCI
resources).
Looks good otherwise.
Linus
^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH 1/1] Add efi e820 memory mapping on x86 [try #1]
2006-07-14 16:09 ` Linus Torvalds
@ 2006-07-16 8:55 ` Edgar Hucek
2006-07-25 4:29 ` Andrew Morton
2006-07-16 9:00 ` [PATCH 1/1] Add force of use MMCONFIG " Edgar Hucek
1 sibling, 1 reply; 29+ messages in thread
From: Edgar Hucek @ 2006-07-16 8:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric W. Biederman, H. Peter Anvin, LKML, akpm
This Patch add an efi e820 memory mapping.
Signed-off-by: Edgar Hucek <hostmaster@ed-soft.at>
diff -uNr linux-2.6.18-rc2/arch/i386/kernel/setup.c
linux-2.6.18-rc2.mactel/arch/i386/kernel/setup.c
--- linux-2.6.18-rc2/arch/i386/kernel/setup.c 2006-07-16
10:38:10.000000000 +0200
+++ linux-2.6.18-rc2.mactel/arch/i386/kernel/setup.c 2006-07-16
10:16:12.000000000 +0200
@@ -414,19 +414,17 @@
{
int x;
- if (!efi_enabled) {
- x = e820.nr_map;
+ x = e820.nr_map;
- if (x == E820MAX) {
- printk(KERN_ERR "Ooops! Too many entries in the memory
map!\n");
- return;
- }
-
- e820.map[x].addr = start;
- e820.map[x].size = size;
- e820.map[x].type = type;
- e820.nr_map++;
+ if (x == E820MAX) {
+ printk(KERN_ERR "Ooops! Too many entries in the memory map!\n");
+ return;
}
+
+ e820.map[x].addr = start;
+ e820.map[x].size = size;
+ e820.map[x].type = type;
+ e820.nr_map++;
} /* add_memory_region */
#define E820_DEBUG 1
@@ -1431,6 +1429,59 @@
#endif
/*
+ * Make a e820 memory map
+ */
+void __init efi_init_e820_map(void)
+{
+ efi_memory_desc_t *md;
+ unsigned long long start = 0;
+ unsigned long long end = 0;
+ unsigned long long size = 0;
+ void *p;
+
+ e820.nr_map = 0;
+
+ for (p = memmap.map; p < memmap.map_end;
+ p += memmap.desc_size) {
+ md = p;
+ switch (md->type) {
+ case EFI_ACPI_RECLAIM_MEMORY:
+ add_memory_region(md->phys_addr, md->num_pages <<
EFI_PAGE_SHIFT, E820_ACPI);
+ break;
+ case EFI_RUNTIME_SERVICES_CODE:
+ case EFI_RUNTIME_SERVICES_DATA:
+ case EFI_RESERVED_TYPE:
+ case EFI_MEMORY_MAPPED_IO:
+ case EFI_MEMORY_MAPPED_IO_PORT_SPACE:
+ case EFI_UNUSABLE_MEMORY:
+ add_memory_region(md->phys_addr, md->num_pages <<
EFI_PAGE_SHIFT, E820_RESERVED);
+ break;
+ case EFI_LOADER_CODE:
+ case EFI_LOADER_DATA:
+ case EFI_BOOT_SERVICES_CODE:
+ case EFI_BOOT_SERVICES_DATA:
+ case EFI_CONVENTIONAL_MEMORY:
+ start = md->phys_addr;
+ size = md->num_pages << EFI_PAGE_SHIFT;
+ end = start + size;
+ if (start < 0x100000ULL && end > 0xA0000ULL) {
+ if (start < 0xA0000ULL)
+ add_memory_region(start, 0xA0000ULL-start, E820_RAM);
+ if (end <= 0x100000ULL)
+ continue;
+ start = 0x100000ULL;
+ size = end - start;
+ }
+ add_memory_region(start, size, E820_RAM);
+ break;
+ case EFI_ACPI_MEMORY_NVS:
+ add_memory_region(md->phys_addr, md->num_pages <<
EFI_PAGE_SHIFT, E820_NVS);
+ break;
+ }
+ }
+}
+
+/*
* Determine if we were loaded by an EFI loader. If so, then we have
also been
* passed the efi memmap, systab, etc., so we should use these data
structures
* for initialization. Note, the efi init code path is determined by the
@@ -1478,9 +1529,11 @@
rd_doload = ((RAMDISK_FLAGS & RAMDISK_LOAD_FLAG) != 0);
#endif
ARCH_SETUP
- if (efi_enabled)
+ if (efi_enabled) {
efi_init();
- else {
+ efi_init_e820_map();
+ print_memory_map("BIOS-EFI");
+ } else {
printk(KERN_INFO "BIOS-provided physical RAM map:\n");
print_memory_map(machine_specific_memory_setup());
}
^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH 1/1] Add force of use MMCONFIG [try #1]
2006-07-14 16:09 ` Linus Torvalds
2006-07-16 8:55 ` [PATCH 1/1] Add efi e820 memory mapping on x86 [try #1] Edgar Hucek
@ 2006-07-16 9:00 ` Edgar Hucek
2006-07-25 4:33 ` Andrew Morton
1 sibling, 1 reply; 29+ messages in thread
From: Edgar Hucek @ 2006-07-16 9:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric W. Biederman, H. Peter Anvin, LKML, akpm
This Patch add force for mmconfig.
On Intel Macs the efi firmaware gives
a different memory map then ACPI_MCFG
provides. This makes the chack wether
to use mmconfig or not fail.
Signed-off-by: Edgar Hucek <hostmaster@ed-soft.at>
diff -uNr linux-2.6.18-rc2/arch/i386/Kconfig linux-2.6.18-rc2.mactel/arch/i386/Kconfig
--- linux-2.6.18-rc2/arch/i386/Kconfig 2006-07-16 10:38:09.000000000 +0200
+++ linux-2.6.18-rc2.mactel/arch/i386/Kconfig 2006-07-16 10:16:12.000000000 +0200
@@ -1027,6 +1027,7 @@
default y
config PCI_MMCONFIG
+ depends on DMI
bool
depends on PCI && ACPI && (PCI_GOMMCONFIG || PCI_GOANY)
default y
diff -uNr linux-2.6.18-rc2/arch/i386/pci/mmconfig.c linux-2.6.18-rc2.mactel/arch/i386/pci/mmconfig.c
--- linux-2.6.18-rc2/arch/i386/pci/mmconfig.c 2006-07-16 10:38:10.000000000 +0200
+++ linux-2.6.18-rc2.mactel/arch/i386/pci/mmconfig.c 2006-07-16 10:18:04.000000000 +0200
@@ -12,6 +12,8 @@
#include <linux/pci.h>
#include <linux/init.h>
#include <linux/acpi.h>
+#include <linux/dmi.h>
+#include <linux/efi.h>
#include <asm/e820.h>
#include "pci.h"
@@ -187,6 +189,54 @@
}
}
+/*
+ * Print system on which MMCONFIG is forced.
+ */
+
+static int pci_mmcfg_force_system(struct dmi_system_id *id)
+{
+ printk(KERN_INFO "PCI: System %s detected. Force MMCONFIG\n",
+ id->ident);
+
+ return 0;
+}
+
+/*
+ * DMI table of forced MMCONFIG systems.
+ */
+
+static struct dmi_system_id __initdata pci_mmcfg_dmi_system_apple[] = {
+ { pci_mmcfg_force_system, "iMac4,1", {
+ DMI_MATCH(DMI_BIOS_VENDOR,"Apple Computer, Inc."),
+ DMI_MATCH(DMI_BIOS_VERSION,"iMac4,1") }},
+ { pci_mmcfg_force_system, "MacBookPro1,1", {
+ DMI_MATCH(DMI_BIOS_VENDOR,"Apple Computer, Inc."),
+ DMI_MATCH(DMI_BIOS_VERSION,"MacBookPro1,1") }},
+ { pci_mmcfg_force_system, "MacBook1,1", {
+ DMI_MATCH(DMI_BIOS_VENDOR,"Apple Computer, Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME,"MacBook1,1")}},
+ { pci_mmcfg_force_system, "Macmini1,1", {
+ DMI_MATCH(DMI_BIOS_VENDOR,"Apple Computer, Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME,"Macmini1,1")}},
+ {},
+};
+
+/*
+ * Check force MMCONFIG.
+ */
+
+int __init pci_mmcfg_force(void)
+{
+ if (efi_enabled) {
+ if (dmi_check_system(pci_mmcfg_dmi_system_apple)) {
+ add_memory_region(pci_mmcfg_config[0].base_address,
+ pci_mmcfg_config[0].base_address + MMCONFIG_APER_MIN, E820_RESERVED);
+ return 1;
+ }
+ }
+ return 0;
+}
+
void __init pci_mmcfg_init(void)
{
if ((pci_probe & PCI_PROBE_MMCONF) == 0)
@@ -198,13 +248,15 @@
(pci_mmcfg_config[0].base_address == 0))
return;
- if (!e820_all_mapped(pci_mmcfg_config[0].base_address,
- pci_mmcfg_config[0].base_address + MMCONFIG_APER_MIN,
- E820_RESERVED)) {
- printk(KERN_ERR "PCI: BIOS Bug: MCFG area at %x is not E820-reserved\n",
- pci_mmcfg_config[0].base_address);
- printk(KERN_ERR "PCI: Not using MMCONFIG.\n");
- return;
+ if (!pci_mmcfg_force()) {
+ if (!e820_all_mapped(pci_mmcfg_config[0].base_address,
+ pci_mmcfg_config[0].base_address + MMCONFIG_APER_MIN,
+ E820_RESERVED)) {
+ printk(KERN_ERR "PCI: BIOS Bug: MCFG area at %x is not E820-reserved\n",
+ pci_mmcfg_config[0].base_address);
+ printk(KERN_ERR "PCI: Not using MMCONFIG.\n");
+ return;
+ }
}
printk(KERN_INFO "PCI: Using MMCONFIG\n");
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Add efi e820 memory mapping on x86 [try #1]
2006-07-16 8:55 ` [PATCH 1/1] Add efi e820 memory mapping on x86 [try #1] Edgar Hucek
@ 2006-07-25 4:29 ` Andrew Morton
2006-07-25 5:17 ` Eric W. Biederman
2006-07-25 5:32 ` Linus Torvalds
0 siblings, 2 replies; 29+ messages in thread
From: Andrew Morton @ 2006-07-25 4:29 UTC (permalink / raw)
To: Edgar Hucek; +Cc: torvalds, ebiederm, hpa, linux-kernel
On Sun, 16 Jul 2006 10:55:30 +0200
Edgar Hucek <hostmaster@ed-soft.at> wrote:
> This Patch add an efi e820 memory mapping.
>
Why?
> /*
> + * Make a e820 memory map
> + */
> +void __init efi_init_e820_map(void)
> +{
> + efi_memory_desc_t *md;
> + unsigned long long start = 0;
> + unsigned long long end = 0;
> + unsigned long long size = 0;
I guess these should have type resource_size_t, given that they ultimately
get remembered via request_resource(). But that has a good chance of
breaking something, so let's leave it alone.
> + add_memory_region(md->phys_addr, md->num_pages <<
> EFI_PAGE_SHIFT, E820_ACPI);
The patch is wordwrapped and will not apply.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Add force of use MMCONFIG [try #1]
2006-07-16 9:00 ` [PATCH 1/1] Add force of use MMCONFIG " Edgar Hucek
@ 2006-07-25 4:33 ` Andrew Morton
2006-07-25 5:27 ` Linus Torvalds
0 siblings, 1 reply; 29+ messages in thread
From: Andrew Morton @ 2006-07-25 4:33 UTC (permalink / raw)
To: Edgar Hucek; +Cc: torvalds, ebiederm, hpa, linux-kernel
On Sun, 16 Jul 2006 11:00:21 +0200
Edgar Hucek <hostmaster@ed-soft.at> wrote:
> This Patch add force for mmconfig.
> On Intel Macs the efi firmaware gives
> a different memory map then ACPI_MCFG
> provides. This makes the chack wether
> to use mmconfig or not fail.
Why do we want to do this? Are the ACPI-provided tables incorrect? If so,
what problems are caused by this?
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Add efi e820 memory mapping on x86 [try #1]
2006-07-25 4:29 ` Andrew Morton
@ 2006-07-25 5:17 ` Eric W. Biederman
2006-07-25 5:32 ` Linus Torvalds
1 sibling, 0 replies; 29+ messages in thread
From: Eric W. Biederman @ 2006-07-25 5:17 UTC (permalink / raw)
To: Andrew Morton; +Cc: Edgar Hucek, torvalds, hpa, linux-kernel
Andrew Morton <akpm@osdl.org> writes:
> On Sun, 16 Jul 2006 10:55:30 +0200
> Edgar Hucek <hostmaster@ed-soft.at> wrote:
>
>> This Patch add an efi e820 memory mapping.
>>
>
> Why?
The x86 architecture needs a way to represent the firmware supplied
memory map in a way that later code can query what is in the map. The
easiest way to do this is simply to convert the efi memory map into
an e820 memory map.
Eric
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Add force of use MMCONFIG [try #1]
2006-07-25 4:33 ` Andrew Morton
@ 2006-07-25 5:27 ` Linus Torvalds
2006-07-26 15:05 ` Andi Kleen
0 siblings, 1 reply; 29+ messages in thread
From: Linus Torvalds @ 2006-07-25 5:27 UTC (permalink / raw)
To: Andrew Morton; +Cc: Edgar Hucek, ebiederm, hpa, linux-kernel
On Mon, 24 Jul 2006, Andrew Morton wrote:
>
> Why do we want to do this? Are the ACPI-provided tables incorrect? If so,
> what problems are caused by this?
The ACPI-provided tables are apparently correct, but we sanity-check them
by _also_ requiring that the mmconfig base address is marked "reserved" in
the e820 tables.
The EFI memory maps apparently don't do that "reserved" marking.
Linus
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Add efi e820 memory mapping on x86 [try #1]
2006-07-25 4:29 ` Andrew Morton
2006-07-25 5:17 ` Eric W. Biederman
@ 2006-07-25 5:32 ` Linus Torvalds
2006-07-25 5:34 ` H. Peter Anvin
2006-07-25 6:00 ` Linus Torvalds
1 sibling, 2 replies; 29+ messages in thread
From: Linus Torvalds @ 2006-07-25 5:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: Edgar Hucek, ebiederm, hpa, linux-kernel
On Mon, 24 Jul 2006, Andrew Morton wrote:
>
> > This Patch add an efi e820 memory mapping.
> >
>
> Why?
EFI is this other Intel brain-damage (the first one being ACPI). It's
totally different from a normal BIOS, and was brought on by ia64, which
never had a BIOS, of course.
Sadly, Apple bought into the whole "BIOS bad, EFI good" hype, so we now
have x86 machines with EFI as the native boot protocol.
The original EFI code in the kernel basically duplicates all the BIOS
interfaces (ie everything that looks at a memory map comes in two
varieties: the normal and tested BIOS e820 variety, and the usually broken
and hacked-up EFI memory map variety).
Translating the EFI memory map to e820 is very much the sane thing to do,
and should have been done by ia64 in the first place. Sadly, EFI people
(a) think that their stinking mess is better than a BIOS and (b) are
historically ia64-only, so they didn't do that, but went the "we'll just
duplicate everything using our inferior EFI interfaces" way.
Edgars patch looks fine per se, I'd just wish we had more testers (or,
alternatively, people would just use bootcamp and make their Apple
machines look like PC's, but see (a) above).
Linus
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Add efi e820 memory mapping on x86 [try #1]
2006-07-25 5:32 ` Linus Torvalds
@ 2006-07-25 5:34 ` H. Peter Anvin
2006-07-25 5:44 ` Linus Torvalds
2006-07-25 6:00 ` Linus Torvalds
1 sibling, 1 reply; 29+ messages in thread
From: H. Peter Anvin @ 2006-07-25 5:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, Edgar Hucek, ebiederm, linux-kernel
Linus Torvalds wrote:
>
> On Mon, 24 Jul 2006, Andrew Morton wrote:
>>> This Patch add an efi e820 memory mapping.
>>>
>> Why?
>
> EFI is this other Intel brain-damage (the first one being ACPI). It's
> totally different from a normal BIOS, and was brought on by ia64, which
> never had a BIOS, of course.
>
You're forgetting PXE.
-hpa
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Add efi e820 memory mapping on x86 [try #1]
2006-07-25 5:34 ` H. Peter Anvin
@ 2006-07-25 5:44 ` Linus Torvalds
2006-07-25 6:26 ` H. Peter Anvin
0 siblings, 1 reply; 29+ messages in thread
From: Linus Torvalds @ 2006-07-25 5:44 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Andrew Morton, Edgar Hucek, ebiederm, linux-kernel
On Mon, 24 Jul 2006, H. Peter Anvin wrote:
>
> You're forgetting PXE.
I don't think I'm forgetting it as much as just repressing it. I don't
think it actually affects the kernel, does it? I assume the only reason
you care is that it might affect a bootloader?
Linus
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Add efi e820 memory mapping on x86 [try #1]
2006-07-25 5:32 ` Linus Torvalds
2006-07-25 5:34 ` H. Peter Anvin
@ 2006-07-25 6:00 ` Linus Torvalds
1 sibling, 0 replies; 29+ messages in thread
From: Linus Torvalds @ 2006-07-25 6:00 UTC (permalink / raw)
To: Andrew Morton; +Cc: Edgar Hucek, ebiederm, hpa, linux-kernel
On Mon, 24 Jul 2006, Linus Torvalds wrote:
>
> Sadly, Apple bought into the whole "BIOS bad, EFI good" hype, so we now
> have x86 machines with EFI as the native boot protocol.
Btw, that's not totally new. I think some people played around with EFI on
x86 even before Apple came around. And don't get me wrong - the problem
with EFI is that it actually superficially looks much better than the
BIOS, but in practice it ends up being one of those things where it has
few real advantages, and often just a lot of extra complexity because of
the "new and improved" interfaces that were largely defined by a
committee.
I think a lot of the "new standards" tend to be that way. Trying to solve
a lot of problems and allow everybody to add their own features, instead
of just saying that it's better to just standardize the hardware.
For example, instead of ACPI, we could just have had standardized hardware
(and a few tables to define things like numbers of CPU's etc). It would
have been simpler for everybody. But no, people seem to think that it's
somehow "better" to have wild and crazy hardware, and then have a really
complicated way of describing it - and driving it - dynamically.
So EFI has this cool shell, a loadable driver framework, and other nice
features. Where "nice" obviously means "much more complex than the simple
things they designed in the late seventies back when people were stupid
and just wanted things to work".
Of course, it's somewhat questionable whether people have actually gotten
smarter or stupider in the last 30 years. It's not enough time for
evolution to have increased our brain capacity, but it certainly _is_
enough time for most people to no longer understand how hardware works any
more.
Not a good combination, in other words.
Not that I'd ever claim that the BIOS is wonderful either, but at least
everybody knows that the BIOS is just a bootloader, and doesn't try to
make it anything else.
The absolutely biggest advantage of a BIOS is that it's _so_ inconvenient
and obviously oldfashioned, that you have to be crazy to want to do
anything serious in it. Real mode, 16-bit code is actually an _advantage_
in that sense. People know how to treat it, and don't get any ideas about
it being some grandiose framework for anything else than "just load the OS
and get the hell out of there".
Linus
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Add efi e820 memory mapping on x86 [try #1]
2006-07-25 5:44 ` Linus Torvalds
@ 2006-07-25 6:26 ` H. Peter Anvin
0 siblings, 0 replies; 29+ messages in thread
From: H. Peter Anvin @ 2006-07-25 6:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, Edgar Hucek, ebiederm, linux-kernel
Linus Torvalds wrote:
>
> On Mon, 24 Jul 2006, H. Peter Anvin wrote:
>> You're forgetting PXE.
>
> I don't think I'm forgetting it as much as just repressing it. I don't
> think it actually affects the kernel, does it? I assume the only reason
> you care is that it might affect a bootloader?
>
Well, one could write an UNDI (PXE) network driver for Linux. Whether
or not one would want to is another matter...
It obviously affects the bootloader.
-hpa
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/1] Add force of use MMCONFIG [try #1]
2006-07-25 5:27 ` Linus Torvalds
@ 2006-07-26 15:05 ` Andi Kleen
0 siblings, 0 replies; 29+ messages in thread
From: Andi Kleen @ 2006-07-26 15:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Edgar Hucek, ebiederm, hpa, linux-kernel, gregkh, akpm
Linus Torvalds <torvalds@osdl.org> writes:
> On Mon, 24 Jul 2006, Andrew Morton wrote:
> >
> > Why do we want to do this? Are the ACPI-provided tables incorrect? If so,
> > what problems are caused by this?
>
> The ACPI-provided tables are apparently correct, but we sanity-check them
> by _also_ requiring that the mmconfig base address is marked "reserved" in
> the e820 tables.
>
> The EFI memory maps apparently don't do that "reserved" marking.
We were planning to remove that heuristic anyways because it produced
far too many false positivies. In fact I think Greg has already
done it. Then that patch should be obsolete.
-Andi
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2006-07-26 15:05 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-06-26 21:19 [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4] Edgar Hucek
2006-06-26 21:33 ` Linus Torvalds
2006-06-27 6:15 ` Edgar Hucek
2006-06-27 6:20 ` Linus Torvalds
2006-06-28 22:37 ` H. Peter Anvin
2006-07-02 17:39 ` Eric W. Biederman
2006-07-02 17:42 ` H. Peter Anvin
2006-07-02 18:26 ` Eric W. Biederman
2006-07-02 18:46 ` Arjan van de Ven
2006-07-05 9:38 ` Edgar Hucek
2006-07-05 15:52 ` Eric W. Biederman
2006-07-13 21:46 ` Edgar Hucek
2006-07-13 22:15 ` Linus Torvalds
2006-07-14 4:23 ` Eric W. Biederman
2006-07-14 6:22 ` H. Peter Anvin
2006-07-14 6:20 ` Edgar Hucek
2006-07-14 16:09 ` Linus Torvalds
2006-07-16 8:55 ` [PATCH 1/1] Add efi e820 memory mapping on x86 [try #1] Edgar Hucek
2006-07-25 4:29 ` Andrew Morton
2006-07-25 5:17 ` Eric W. Biederman
2006-07-25 5:32 ` Linus Torvalds
2006-07-25 5:34 ` H. Peter Anvin
2006-07-25 5:44 ` Linus Torvalds
2006-07-25 6:26 ` H. Peter Anvin
2006-07-25 6:00 ` Linus Torvalds
2006-07-16 9:00 ` [PATCH 1/1] Add force of use MMCONFIG " Edgar Hucek
2006-07-25 4:33 ` Andrew Morton
2006-07-25 5:27 ` Linus Torvalds
2006-07-26 15:05 ` Andi Kleen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).