Eric Lee / smarc-fsl-linux-kernel

12 Jan, 2012

1 commit

  • bcede2f64   Merge branch 'x86-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip ... Browse Code »

    * 'x86-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
    x86, efi: Break up large initrd reads
    x86, efi: EFI boot stub support
    efi: Add EFI file I/O data types
    efi.h: Add boottime->locate_handle search types
    efi.h: Add graphics protocol guids
    efi.h: Add allocation types for boottime->allocate_pages()
    efi.h: Add efi_image_loaded_t
    efi.h: Add struct definition for boot time services
    x86: Don't use magic strings for EFI loader signature
    x86: Add missing bzImage fields to struct setup_header

    Linus Torvalds
     

13 Dec, 2011

1 commit

  • e1ad783b1   Revert "x86, efi: Calling __pa() with an ioremap()ed address is invalid" ... Browse Code »

    This hangs my MacBook Air at boot time; I get no console
    messages at all. I reverted this on top of -rc5 and my machine
    boots again.

    This reverts commit e8c7106280a305e1ff2a3a8a4dfce141469fb039.

    Signed-off-by: Matt Fleming
    Signed-off-by: Keith Packard
    Acked-by: H. Peter Anvin
    Cc: Matthew Garrett
    Cc: Zhang Rui
    Cc: Huang Ying
    Cc: Linus Torvalds
    Cc: Andrew Morton
    Link: http://lkml.kernel.org/r/1321621751-3650-1-git-send-email-matt@console
    Signed-off-by: Ingo Molnar

    Keith Packard
     

10 Dec, 2011

1 commit

09 Dec, 2011

1 commit

  • e8c710628   x86, efi: Calling __pa() with an ioremap()ed address is invalid ... Browse Code »

    If we encounter an efi_memory_desc_t without EFI_MEMORY_WB set
    in ->attribute we currently call set_memory_uc(), which in turn
    calls __pa() on a potentially ioremap'd address.

    On CONFIG_X86_32 this is invalid, resulting in the following
    oops on some machines:

    BUG: unable to handle kernel paging request at f7f22280
    IP: [] reserve_ram_pages_type+0x89/0x210
    [...]

    Call Trace:
    [] ? page_is_ram+0x1a/0x40
    [] reserve_memtype+0xdf/0x2f0
    [] set_memory_uc+0x49/0xa0
    [] efi_enter_virtual_mode+0x1c2/0x3aa
    [] start_kernel+0x291/0x2f2
    [] ? loglevel+0x1b/0x1b
    [] i386_start_kernel+0xbf/0xc8

    A better approach to this problem is to map the memory region
    with the correct attributes from the start, instead of modifying
    it after the fact. The uncached case can be handled by
    ioremap_nocache() and the cached by ioremap_cache().

    Despite first impressions, it's not possible to use
    ioremap_cache() to map all cached memory regions on
    CONFIG_X86_64 because EFI_RUNTIME_SERVICES_DATA regions really
    don't like being mapped into the vmalloc space, as detailed in
    the following bug report,

    https://bugzilla.redhat.com/show_bug.cgi?id=748516

    Therefore, we need to ensure that any EFI_RUNTIME_SERVICES_DATA
    regions are covered by the direct kernel mapping table on
    CONFIG_X86_64. To accomplish this we now map E820_RESERVED_EFI
    regions via the direct kernel mapping with the initial call to
    init_memory_mapping() in setup_arch(), whereas previously these
    regions wouldn't be mapped if they were after the last E820_RAM
    region until efi_ioremap() was called. Doing it this way allows
    us to delete efi_ioremap() completely.

    Signed-off-by: Matt Fleming
    Cc: H. Peter Anvin
    Cc: Matthew Garrett
    Cc: Zhang Rui
    Cc: Huang Ying
    Cc: Linus Torvalds
    Cc: Andrew Morton
    Link: http://lkml.kernel.org/r/1321621751-3650-1-git-send-email-matt@console-pimps.org
    Signed-off-by: Ingo Molnar

    Matt Fleming
     

10 May, 2011

1 commit

  • 9cd2b07c1   x86, efi: Consolidate EFI nx control ... Browse Code »

    The core EFI code and 64-bit EFI code currently have independent
    implementations of code for setting memory regions as executable or not.
    Let's consolidate them.

    Signed-off-by: Matthew Garrett
    Link: http://lkml.kernel.org/r/1304623186-18261-2-git-send-email-mjg@redhat.com
    Signed-off-by: H. Peter Anvin

    Matthew Garrett
     

28 Aug, 2010

1 commit

04 Aug, 2009

1 commit

  • 6a7bbd57e   x86: Make 64-bit efi_ioremap use ioremap on MMIO regions ... Browse Code »

    Booting current 64-bit x86 kernels on the latest Apple MacBook
    (MacBook5,2) via EFI gives the following warning:

    [ 0.182209] ------------[ cut here ]------------
    [ 0.182222] WARNING: at arch/x86/mm/pageattr.c:581 __cpa_process_fault+0x44/0xa0()
    [ 0.182227] Hardware name: MacBook5,2
    [ 0.182231] CPA: called for zero pte. vaddr = ffff8800ffe00000 cpa->vaddr = ffff8800ffe00000
    [ 0.182236] Modules linked in:
    [ 0.182242] Pid: 0, comm: swapper Not tainted 2.6.31-rc4 #6
    [ 0.182246] Call Trace:
    [ 0.182254] [] ? __cpa_process_fault+0x44/0xa0
    [ 0.182261] [] warn_slowpath_common+0x78/0xd0
    [ 0.182266] [] warn_slowpath_fmt+0x64/0x70
    [ 0.182272] [] ? update_page_count+0x3c/0x50
    [ 0.182280] [] ? phys_pmd_init+0x140/0x22e
    [ 0.182286] [] __cpa_process_fault+0x44/0xa0
    [ 0.182292] [] __change_page_attr_set_clr+0x5f0/0xb40
    [ 0.182301] [] ? vm_unmap_aliases+0x175/0x190
    [ 0.182307] [] change_page_attr_set_clr+0xfe/0x3d0
    [ 0.182314] [] _set_memory_uc+0x2a/0x30
    [ 0.182319] [] set_memory_uc+0x7b/0xb0
    [ 0.182327] [] efi_enter_virtual_mode+0x2ad/0x2c9
    [ 0.182334] [] start_kernel+0x2db/0x3f4
    [ 0.182340] [] x86_64_start_reservations+0x99/0xb9
    [ 0.182345] [] x86_64_start_kernel+0xe0/0xf2
    [ 0.182357] ---[ end trace 4eaa2a86a8e2da22 ]---
    [ 0.182982] init_memory_mapping: 00000000ffffc000-0000000100000000
    [ 0.182993] 00ffffc000 - 0100000000 page 4k

    This happens because the 64-bit version of efi_ioremap calls
    init_memory_mapping for all addresses, regardless of whether they are
    RAM or MMIO. The EFI tables on this machine ask for runtime access to
    some MMIO regions:

    [ 0.000000] EFI: mem195: type=11, attr=0x8000000000000000, range=[0x0000000093400000-0x0000000093401000) (0MB)
    [ 0.000000] EFI: mem196: type=11, attr=0x8000000000000000, range=[0x00000000ffc00000-0x00000000ffc40000) (0MB)
    [ 0.000000] EFI: mem197: type=11, attr=0x8000000000000000, range=[0x00000000ffc40000-0x00000000ffc80000) (0MB)
    [ 0.000000] EFI: mem198: type=11, attr=0x8000000000000000, range=[0x00000000ffc80000-0x00000000ffca4000) (0MB)
    [ 0.000000] EFI: mem199: type=11, attr=0x8000000000000000, range=[0x00000000ffca4000-0x00000000ffcb4000) (0MB)
    [ 0.000000] EFI: mem200: type=11, attr=0x8000000000000000, range=[0x00000000ffcb4000-0x00000000ffffc000) (3MB)
    [ 0.000000] EFI: mem201: type=11, attr=0x8000000000000000, range=[0x00000000ffffc000-0x0000000100000000) (0MB)

    This arranges to pass the EFI memory type through to efi_ioremap, and
    makes efi_ioremap use ioremap rather than init_memory_mapping if the
    type is EFI_MEMORY_MAPPED_IO. With this, the above warning goes away.

    Signed-off-by: Paul Mackerras
    LKML-Reference:
    Cc: Huang Ying
    Signed-off-by: H. Peter Anvin

    Paul Mackerras
     

05 Mar, 2009

1 commit

  • dd39ecf52   x86: EFI: Back efi_ioremap with init_memory_mapping instead of FIX_MAP ... Browse Code »

    Impact: Fix boot failure on EFI system with large runtime memory range

    Brian Maly reported that some EFI system with large runtime memory
    range can not boot. Because the FIX_MAP used to map runtime memory
    range is smaller than run time memory range.

    This patch fixes this issue by re-implement efi_ioremap() with
    init_memory_mapping().

    Reported-and-tested-by: Brian Maly
    Signed-off-by: Huang Ying
    Cc: Brian Maly
    Cc: Yinghai Lu
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Huang Ying
     

30 Dec, 2008

1 commit

23 Oct, 2008

2 commits