Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[Edgar Hucek <hostmaster@ed-soft.at>]

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
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/